lparstat -i
Node Name : ****
Partition Name : ****
Partition Number : 1
Type : Shared-SMT
Mode : Capped
Entitled Capacity : 2.00
Partition Group-ID : 32769
Shared Pool ID : 0
Online Virtual CPUs : 4
Maximum Virtual CPUs : 4
Minimum Virtual CPUs : 2
Online Memory : 16384 MB
Maximum Memory : 20480 MB
Minimum Memory : 8192 MB
Variable Capacity Weight : 0
Minimum Capacity : 1.00
Maximum Capacity : 4.00
Capacity Increment : 0.01
Maximum Physical CPUs in system : 16
Active Physical CPUs in system : 16
Active CPUs in Pool : 16
Shared Physical CPUs in system : 16
Maximum Capacity of Pool : 1600
Entitled Capacity of Pool : 1400
Unallocated Capacity : 0.00
Physical CPU Percentage : 50.00%
Unallocated Weight : 0
Desired Virtual CPUs : 4
Desired Memory : 16384 MB
Desired Variable Capacity Weight : 0
Desired Capacity : 2.00
I see 8 "CPU"(Cores) in topas. Is every topas-CPU limited to 25% of one physical core? Or if only one topas-CPU is used, could it gain 100% from one physical Core?
Thx
Talulah
---------- Post updated 02-02-11 at 06:28 AM ---------- Previous update was 01-02-11 at 05:46 PM ----------
There is a feature called Simultaneous Multi Threading (SMT) which adds a 2nd hardware thread, that is being shown in some tools as another CPU. Usually they are referred to as "Logical CPUs".
To see a list of the Logical CPU distribution, type smtctl .
With AIX 7 installed on p7, you have even 3 additional CPU threads per Virtual CPU, which will give you 4 Logical CPUs per Virtual CPU when SMT is enabled.
If you got more AIX particular questions, I suggest posting them in the AIX subforum here next time so they have a higher chance to get an answer. Moving this thread there.
You have a capped LPAR, which means that the maximum number of CPU power you get is 200 processing units (entitled capacity).
These units are presented as four virtual CPU's to the OS, SMT doubles this number to eightlogical CPU's. So the eight CPU's you see are not eight cores. Only 2 cores can be used by the LPAR in this configuration.
In this configuration:
If exactly one process with 100% virtual CPU utilization runs, then used this only 50% or up to 100% of one physical CPU?
I think it can only occupy 50% of a physical CPU, because there are allocated only 2.0 and these are distributed evenly on this 4 virtual CPU. This would mean that it would only be possible with at least 4 processes to exhaust the entitled 2.0 capacity and one single process would be run faster with the following setting:
Unfortunately, I find nothing in this Redbook ( sg247940 )
What do you think?
To test this:
Is on a standard AIX system a tool available that accurately initiates one process and utilizes a CPU for a certain time and then outputs as many calculations could run it?
I had a similar question about the monitoring of CPU usage on logical CPUs. I was trying to sort out some nmon reports and came to no conclusion. So I asked Nigel Griffiths (coder of nmon) in the IBM developerWorks forum about it:
---------- Post updated at 04:38 PM ---------- Previous update was at 02:17 PM ----------
In addition to my previous somewhat general post:
Your assumption sounds correct to me, if the process is single threaded. If it is multithreaded and SMT is enabled, it should be dispatched by different logical CPUs and so take advantage being able to run multiple threads on multiple logical CPUs.
You can check dispatching with mpstat -s 1 for example.
There is also a "Virtualization best practices" Redbook - maybe this has information about it.
A single threaded process will most probably not take any advantage of SMT or having more than 1 virtual CPU available, if it is running mainly alone on the system. It can only be handled by one virtual CPU at a time. Though a second virtual CPU can meanwhile handle other operating system tasks etc. In that case turn of SMT and monitor it's performance.
You might want to check out what is best for your environment/application.
To check out if your application is multithreaded, check it out with svmon -P| grep -p Pid . There will be a Y in the column for Mthrd.
In our environments we have SMT turned on, because on every LPAR there is usually running single and multithreaded processes and we had no need to turn SMT yet off.
...