I have a simple mono-threaded application that does almost pure processing
It uses two int buffers of the same size
It reads one-by-one all the values of the first buffer
each value is a random index in the second buffer
It reads the value at the index in the second buffer
It sums all the values taken from the second buffer
It does all the previous steps for bigger and bigger
At the end, I print the number of voluntary and involuntary CPU context switches
If the size of the buffers become quite big, my PC starts to slow down: why? I have 4 cores with hyper-threading so 3 cores are remaing. Only one is 100% busy. Is it because my process uses almost 100% for the "RAM-bus"?
Then, I created a CPU-set that I want to dedicate to my process (my CPU-set contains both CPU-threads of the same core)
$ cat /sys/devices/system/cpu/cpu3/topology/core_id
3
$ cat /sys/devices/system/cpu/cpu7/topology/core_id
3
$ cset set -c 3,7 -s my_cpuset
$ cset set -l
cset:
Name CPUs-X MEMs-X Tasks Subs Path
------------ ---------- - ------- - ----- ---- ----------
root 0-7 y 0 y 934 1 /
my_cpuset 3,7 n 0 n 0 0 /my_cpuset
It seems that absolutely no task at all is running on my CPU-set. I can relaunch my process and while it is running, I launch:
$ taskset -c 7 ./TestCpuset # Here, I launch my process
...
$ ps -mo pid,tid,fname,user,psr -p 25244 # 25244 being the PID of my process
PID TID COMMAND USER PSR
25244 - TestCpus phil -
- 25244 - phil 7
PSR = 7: my process is well running on the expected CPU-thread. I hope it is the only one running on it but at the end, my process displays:
Number of voluntary context switch: 2
Number of involuntary context switch: 1231
If I had involuntary context switches, it means that other processes are running on my core: How is it possible? What must I do in order to get Number of involuntary context switch = 0?
Last question: When my process is running, if I launch
$ cset set -l
cset:
Name CPUs-X MEMs-X Tasks Subs Path
------------ ---------- - ------- - ----- ---- ----------
root 0-7 y 0 y 1031 1 /
my_cpuset 3,7 n 0 n 0 0 /my_cpuset
Once again I get 0 tasks on my CPU-set. But I know that there is a process running on it: it seems that a task is not a process?
If the size of the buffers become quite big, my PC starts to slow down: why? I have 4 cores with hyper-threading so 3 cores are remaing. Only one is 100% busy. Is it because my process uses almost 100% for the "RAM-bus"?
You reached the hardware performance limit of a single-threaded application, that is 100% CPU time on the single CPU your program is allocated to. Your application thread will not run on more than one CPU at a time (reference).
What must I do in order to get Number of involuntary context switch = 0?
Aren't you missing --cpu_exclusive option in cset set command?
By the way, if you want to achieve lower execution time, i suggest you to make a multithreaded application and let operating system, and the hardware beneath parallelize execution instead. Locking a process to a CPU set and preventing it from doing context-switch might degrade the operating system performance and is not a portable solution.
Related
I want to see the real change in process launch and execution after changing nice value.
When i allocate lower nice value to process, what changes should i see.
$ps -l |head -2
UID PID PPID F CPU PRI NI SZ RSS WCHAN S
501 25164 25144 4006 0 31 10 4280144 1584 - SN+
I executed
$renice -6 25164
and i got new value of NICENESS as -6 ,it was 10 before
ps -l |head -2
UID PID PPID F CPU PRI NI SZ RSS WCHAN S
501 25164 25144 4006 0 31 -6 4280144 1584 - S<+
So, what changes i should see now. i.e Should it increase processing speed .
or launch time will be less.
$renice -6 pid
I want to see the changes in process execution time, as it gets higher priority .What benefit user will get?
You will only see a difference in execution time if the cpu is fully utilized since the niceness affects the priority of a process. So to benchmark a difference you will need to run some other program that fully utilizes the cpu and then run the program you are benchmarking. Then change the niceness so that the priority is now more or less than the other program and you will then see a difference in execution time.
I want to gather how many threads does a process use (from their PID/status i guess) and after that i wanna compare them and output the biggest number of them. For example i wanna gather all threads per chromium's processes and then compare the numbers and output the max. Any ideas?
E.g
2131 Threads : 20 , 2341 Threads : 10 , 2200 Threads : 5
Max Threads = 20
in ubuntu you can get no of thread for process using this command
ps -o nlwp `pgrep process_name`
nlwp stands for number of light weight process
How can I grab the percentage of cpu usage on a per process basis? So, for example, I'd like to run my program prog and get the cpu usage it incurred in, for example:
prog name cpu0 cpu1 cpu2 cpu3 total
prog 15 20 45 47 127%
Is there any tool for this?
Thanks.
I think that you can make use of the information in /proc/[pid]/stat and /proc/stat to estimate this.
Check out the great answers to How to calculate the CPU usage of a process by PID in Linux from C? which explain how to calculate CPU usage % for a single processor.
The 6th from last number you get from /proc/[pid]/stat is "processor %d, CPU number last executed on" (on Ubuntu 12.04 at least).
To extend to multiple processors, you could sample the CPU usage over a period and (very roughly!) estimate the proportion of time on each processor. Then use these proportions to split the CPU usage between the processors. Based on the info in /proc/stat you can also sample the total time for each processor and then you have all the variables you need!
See http://linux.die.net/man/5/proc for more info about proc.
For firefox:
while [ 1 ]; do ps --no-heading -C firefox -L -o command,psr,pcpu|sort -k 2 -n; echo; sleep 1; done
You'd have to sum the third column (which I see no ridiculously easy way to do) because it's actually showing you every thread. First column is name, second processor, third, %cpu.
linux process explorer project provides this functionality, you can see a graph for the CPU/Memory/IO for each process in the properties dialog.
Here is a simple python i've made:
import re,time,sys
cpuNum=0
if len(sys.argv)==1:
print "use pidcpu <pid1,pid2,..,pidn>"
sys.exit(0)
pids=sys.argv.pop()
def getCpuTot():
global cpuNum
f=open("/proc/stat","r")
ln=f.read()
f.close()
#cpu 858286704 148088 54216880 117129864 2806189 5046 16997674 0 0 0
r=re.findall("cpu[\d\s]{1}\s+(\d+)\s(\d+)\s(\d+)\s(\d+)\s.*?",ln,re.DOTALL)
cpuNum=len(r)-1
return int(r[0][0])+int(r[0][1])+int(r[0][2])+int(r[0][3])
def getPidCPU(pid):
f=open("/proc/"+ str(pid) +"/stat","r")
ln=f.readline()
f.close()
a=ln.split(" ")
return int(a[13])+int(a[14])
cpu1=getCpuTot()
cpupid1=[]
for pid in pids.split(","):
cpupid1.append(getPidCPU(pid))
time.sleep(1)
cpu2=getCpuTot()
cpupid2=[]
for pid in pids.split(","):
cpupid2.append(getPidCPU(pid))
i=0
for pid in pids.split(","):
perc=int(cpuNum*(cpupid2[i]-cpupid1[i])*100/float(cpu2-cpu1))
i+=1
print pid,perc
Note on pri from ps man page:
"pri PRI priority of the process. Higher number means lower priority"
Consider PID 26073 here
$ renice +15 26073
26073: old priority 5, new priority 15 # I am making this process more nice
$ ps -t 1 -o pid,ppid,%cpu,stat,cmd,bsdstart,time,pri
PID PPID %CPU STAT CMD START TIME PRI
9115 18136 0.0 Ss bash 17:10 00:00:01 19
26073 9115 12.0 RN+ p4 sync 19:06 00:02:56 4
STAT = RN+ which means : Running , low-prio ( nice to others), foreground. PRI=4 (1)
$ sudo renice -10 26073
26073: old priority 15, new priority -10 # I am making this process less nice
$ ps -t 1 -o pid,ppid,%cpu,stat,cmd,bsdstart,time,pri
PID PPID %CPU STAT CMD START TIME PRI
9115 18136 0.0 Ss bash 17:10 00:00:01 19
26073 9115 12.0 S<+ p4 sync 19:06 00:03:15 29
STAT = S<+ which means : Interruptible sleep , high-prio ( not nice to others), foreground. PRI=29 (2)
In case 2 the process priority increased or to say it another way the process became higher priority.
But this contradicts what definition of pri says from man page ( that higher number means lower priority)
You are being confused by PRI (immediate priority) vs. NICE (the assigned priority). PRI often gets a boost (i.e. lower value) when a process is being restarted after blocking on I/O, and conversely is lowered (higher value) if it uses up its scheduler-assigned time slot without blocking, at least with the standard scheduler. Many systems have alternative schedulers with different behaviors, but in all cases PRI is the actual current priority that the scheduler has assigned; this value is influenced by, but not defined by, the assigned "niceness".
Reference on Linux's priority management here: http://oreilly.com/catalog/linuxkernel/chapter/ch10.html
Although I'm not an expert on the linux scheduler, I do know that it 'punishes' CPU bound processes and rewards I/O bound processes (something most schedulers do to a greater or lesser extent). As explained, this and other adjustments, along with the NICE value, result in an internal priority setting within the scheduler. The fact that they use an inverse NICE value and a non-inverse internal PRI value is somewhat confusing, but makes sense.
Trying to determine the Processor Queue Length (the number of processes that ready to run but currently aren't) on a linux machine. There is a WMI call in Windows for this metric, but not knowing much about linux I'm trying to mine /proc and 'top' for the information. Is there a way to determine the queue length for the cpu?
Edit to add: Microsoft's words concerning their metric: "The collection of one or more threads that is ready but not able to run on the processor due to another active thread that is currently running is called the processor queue."
sar -q will report queue length, task list length and three load averages.
Example:
matli#tornado:~$ sar -q 1 0
Linux 2.6.27-9-generic (tornado) 01/13/2009 _i686_
11:38:32 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15
11:38:33 PM 0 305 1.26 0.95 0.54
11:38:34 PM 4 305 1.26 0.95 0.54
11:38:35 PM 1 306 1.26 0.95 0.54
11:38:36 PM 1 306 1.26 0.95 0.54
^C
vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 0 256368 53764 75980 220564 2 28 60 54 774 1343 15 4 78 2
The first column (r) is the run queue - 2 on my machine right now
Edit: Surprised there isn't a way to just get the number
Quick 'n' dirty way to get the number (might vary a little on different machines):
vmstat|tail -1|cut -d" " -f2
The metrics you seek exist in /proc/schedstat.
The format of this file is described in sched-stats.txt in the kernel source. Specifically, the cpu<N> lines are what you want:
CPU statistics
--------------
cpu<N> 1 2 3 4 5 6 7 8 9
First field is a sched_yield() statistic:
1) # of times sched_yield() was called
Next three are schedule() statistics:
2) This field is a legacy array expiration count field used in the O(1)
scheduler. We kept it for ABI compatibility, but it is always set to zero.
3) # of times schedule() was called
4) # of times schedule() left the processor idle
Next two are try_to_wake_up() statistics:
5) # of times try_to_wake_up() was called
6) # of times try_to_wake_up() was called to wake up the local cpu
Next three are statistics describing scheduling latency:
7) sum of all time spent running by tasks on this processor (in jiffies)
8) sum of all time spent waiting to run by tasks on this processor (in
jiffies)
9) # of timeslices run on this cpu
In particular, field 8. To find the run queue length, you would:
Observe field 8 for each CPU and record the value.
Wait for some interval.
Observe field 8 for each CPU again, and calculate how much the value has increased.
Dividing that difference by the length of the time interval waited (the documentation says it's in jiffies, but it's actually in nanoseconds since the addition of CFS), by Little's Law, yields the mean length of the scheduler run queue over the interval.
Unfortunately, I'm not aware of any utility to automate this process which is usually installed or even packaged in a Linux distribution. I've not used it, but the kernel documentation suggests http://eaglet.rain.com/rick/linux/schedstat/v12/latency.c, which unfortunately refers to a domain that is no longer resolvable. Fortunately, it's available on the wayback machine.
Why not sar or vmstat?
These tools report the number of currently runnable processes. Certainly if this number is greater than the number of CPUs, some of them must be waiting. However, processes can still be waiting even when the number of processes is less than the number of CPUs, for a variety of reasons:
A process may be pinned to a particular CPU.
The scheduler may decide to schedule a process on a particular CPU to make better utilization of cache, or for NUMA optimization reasons.
The scheduler may intentionally idle a CPU to allow more time to a competing, higher priority process on another CPU that shares the same execution core (a hyperthreading optimization).
Hardware interrupts may be processable only on particular CPUs for a variety of hardware and software reasons.
Moreover, the number of runnable processes is only sampled at an instant in time. In many cases this number may fluctuate rapidly, and the contention may be occurring between the times the metric is being sampled.
These things mean the number of runnable processes minus the number of CPUs is not a reliable indicator of CPU contention.
uptime will give you the recent load average, which is approximately the average number of active processes. uptime reports the load average over the last 1, 5, and 15 minutes. It's a per-system measurement, not per-CPU.
Not sure what the processor queue length in Windows is, hopefully it's close enough to this?