Messages in this thread | | | Subject | Re: [PATCH] sched/cputime: Ensure correct utime and stime proportion | From | Xunlei Pang <> | Date | Mon, 9 Jul 2018 13:52:38 +0800 |
| |
Hi Peter,
On 7/5/18 9:21 PM, Xunlei Pang wrote: > On 7/5/18 6:46 PM, Peter Zijlstra wrote: >> On Wed, Jun 27, 2018 at 08:22:42PM +0800, Xunlei Pang wrote: >>> tick-based whole utime is utime_0, tick-based whole stime >>> is stime_0, scheduler time is rtime_0. >> >>> For a long time, the process runs mainly in userspace with >>> run-sleep patterns, and because two different clocks, it >>> is possible to have the following condition: >>> rtime_0 < utime_0 (as with little stime_0) >> >> I don't follow... what? >> >> Why are you, and why do you think it makes sense to, compare rtime_0 >> against utime_0 ? >> >> The [us]time_0 are, per your earlier definition, ticks. They're not an >> actual measure of time. Do not compare the two, that makes no bloody >> sense. >> > > [us]time_0 is task_struct:utime{stime}, I cited directly from > cputime_adjust(), both in nanoseconds. I assumed "rtime_0 < utime_0" > here to simple the following proof to help explain the problem we met. >
Please see the enclosure for the reproducer cputime_adjust.tgz (process_top.sh, usr_sys.c): gcc usr_sys.c -o usr_sys Firstly, the function consume_sys() in usr_sys.c yields 100% sys which can be verified as follows: $ taskset -c 0 ./usr_sys 1 $ ./process_top.sh $(pidof usr_sys) 0.0 usr, 100.0 sys 0.0 usr, 100.0 sys
Tested on my local box on 4.17.0 by executing "taskset -c 0 ./usr_sys", then executing "./process_top.sh $(pidof usr_sys)" to watch. 1) Before this patch 50.0 usr, 0.0 sys 50.0 usr, 1.0 sys 50.0 usr, 0.0 sys 50.0 usr, 0.0 sys 49.0 usr, 4.0 sys //switch to consume 100% sys, ignore this line 12.0 usr, 88.0 sys 11.0 usr, 89.0 sys 10.0 usr, 90.0 sys 10.0 usr, 90.0 sys 9.0 usr, 91.0 sys 8.0 usr, 91.0 sys
Obviously there were around 10% sys wrongly goes to usr
2) After this patch 50.0 usr, 0.0 sys 50.0 usr, 0.0 sys 50.0 usr, 0.0 sys 50.0 usr, 0.0 sys 11.0 usr, 76.0 sys //switch to consume 100% sys, ignore this line 1.0 usr, 100.0 sys 0.0 usr, 100.0 sys 1.0 usr, 100.0 sys 0.0 usr, 100.0 sys 0.0 usr, 100.0 sys
So it displayed the correct result as we expected after this patch.
Thanks, Xunlei [unhandled content-type:application/x-gzip] | |