On Sat, 23 Jan 2010 23:38:08 +0100, Garrett Cooper <[email protected]> wrote:
> 2010/1/22 Jiří Paleček <[email protected]>: >> On Wed, 20 Jan 2010 03:52:48 +0100, Garrett Cooper <[email protected]> >> wrote: >> >>> On Tue, Jan 19, 2010 at 4:30 PM, Jiri Palecek <[email protected]> wrote: >>>> >>>> On Wednesday 06 January 2010 10:47:34 Shi Weihua wrote: >>>>> >>>>> at 2010-1-6 13:24, Garrett Cooper wrote: >>>>> > On Tue, Jan 5, 2010 at 8:58 PM, Shi Weihua <[email protected]> >>>>> > wrote: >>>>> >> Some abnormal messages outputted in my x86_64. >>>>> >> ------------------- >>>>> >> pid 4622 cpu_usage 0 >>>>> >> cpuctl_test_fj 1 TFAIL : case19 FAIL >>>>> >> pid 4646 cpu_usage 0 >>>>> >> cpuctl_test_fj 1 TFAIL : case20 FAIL >>>>> >> pid 4670 cpu_usage 63 >>>>> >> cpuctl_test_fj 1 TFAIL : case21 FAIL >>>>> >> ------------------- >>>>> >> I think cpu usage's computation error occured. >>>>> >> So I tried to use the oldest arithmetic of cpu usage, fortunately >>>>> it >>>>> >> works. >>>>> >> Maybe we should replace 'ps' by 'top' in get_cpu_usage(). >>>>> >> By the way, I increased the admissible range of cpu usage in >>>>> case21() >>>>> >> because it jumps out range of 44-56 sometimes. >>>>> >> >>>>> >> My patch works now: >>>>> >> ------------------- >>>>> >> pid 20277 cpu_usage 97 >>>>> >> cpuctl_test_fj 1 TPASS : case19 PASS >>>>> >> pid 20307 cpu_usage 99 >>>>> >> cpuctl_test_fj 1 TPASS : case20 PASS >>>>> >> pid 20336 cpu_usage 55 >>>>> >> pid 20336 cpu_usage 53 >>>>> >> pid 20336 cpu_usage 55 >>>>> >> pid 20336 cpu_usage 57 >>>>> >> pid 20336 cpu_usage 55 >>>>> >> pid 20336 cpu_usage 55 >>>>> >> pid 20336 cpu_usage 55 >>>>> >> pid 20336 cpu_usage 55 >>>>> >> pid 20336 cpu_usage 57 >>>>> >> pid 20336 cpu_usage 53 >>>>> >> cpuctl_test_fj 1 TPASS : case21 PASS >>>>> >> ------------------- >>>>> >> >>>>> >> Signed-off-by: Shi Weihua <[email protected]> >>>>> >> --- >>>>> >> --- >>>>> >> >>>>> ltp-full-20091231/testcases/kernel/controllers/cpuctl_fj/run_cpuctl_test_fj.sh >>>>> >> 2009-11-16 15:40:40.000000000 +0800 >>>>> >> +++ >>>>> >> >>>>> ltp-full-20091231.new/testcases/kernel/controllers/cpuctl_fj/run_cpuctl_test_fj.sh >>>>> >> 2010-01-06 12:36:32.000000000 +0800 >>>>> >> @@ -85,7 +85,10 @@ creat_process() >>>>> >> >>>>> >> get_cpu_usage() >>>>> >> { >>>>> >> - ps -eo 'pid,pcpu' | awk '$1 == "'$1'" { >>>>> >> sub(/(\.[[:digit:]])*$/, "", $2); print $2 }' >>>>> >> + top=($(top -b -n 1 -p $1 | tail -2 | head -1)) >>>>> >> + top=${top[8]} >>>>> >> + top=`echo $top | awk -F "." '{print $1}'` >>>>> >> + echo "$top" >>>>> >> } >>>>> >> >>>>> >> kill_all_pid() >>>>> >> @@ -627,7 +630,7 @@ case21() >>>>> >> do >>>>> >> cpu_usage=$(get_cpu_usage $pid) >>>>> >> echo "pid $pid cpu_usage $cpu_usage" >>>>> >> - expr 44 \< "$cpu_usage" \& "$cpu_usage" \< 56 > >>>>> >> /dev/null 2>&1 >>>>> >> + expr 40 \< "$cpu_usage" \& "$cpu_usage" \< 60 > >>>>> >> /dev/null 2>&1 >>>>> >> ret=$? >>>>> >> : $(( top_times+=1 )) >>>>> >> done >>>>> > >>>>> > Could you add a set -x to the top of the script so we can see >>>>> the >>>>> > output please? ps --version would be helpful too.. >>>>> >>>>> I wish it can help you. >>>>> --------------------- sh -x ----------------------------- >>>>> + for i in '$(seq 1 $TST_TOTAL)' >>>>> + setup >>>> >>>> [ ... snip ... ] >>>> >>>> I believe Garrett Cooper meant to send the trace output of the >>>> original >>>> script (the one with ps). >>>> >>>> However, I'm not sure about the awk program there - particularly: >>>> >>>> sub(/(\.[[:digit:]])*$/, "", $2) >>>> >>>> should probably be >>>> >>>> sub(/\.[[:digit:]]*$/, "", $2) >>>> >>>> (without the group). Not sure if this can actually cause what you see. >>>> >>>> Also, I think we could simplify it a bit further, to something like >>>> this: >>>> >>>> get_cpu_usage() >>>> { >>>> ps -p $1 -o pcpu= | awk -F "." '{print $1}' >>>> } >>>> >>>> Please, tell me what do you think about it. >>> >>> Actually he gave me what I needed (forgot to reply because I >> >> Yes, but it doesn't cast much light on the problem that it didn't work >> for >> Shi Weihua in the first place. >> >>> didn't star the email); I'm pretty sure that your observation is >>> correct: we shouldn't be extracting \. unless we're actually going to >>> use it, so the ellipses [\(\)] can be removed. >>> Are we using just the `major' number, or are we using the `minor' >>> number in the cpu usage? >> >> You mean integral and fractional part? I guess the integral part only. > > Does expr(1) do float point comparisons (this is where the issue was > coming from I think...)? > > gcoo...@optimus ~ $ expr 0 \< 42.0 \& 42.0 \< 100 > 0 > gcoo...@optimus ~ $ expr 0.0 \< 42.0 \& 42.0 \< 100.0 > 0 > > I checked in a copy based on your suggestion Jiri so folks would hit > this issue, but I'm curious as to why integers are the only things > supported by expr(1) when comparing ranges. Obviously, only integers are supported by expr. That's the way it is. Not that I think we (or this test) actually need floating point numbers - we can happily use integral approximations when testing against interval 40-60. But Shi Weihua's mail indicated that he gets 0 (zero) from that function, so I guess it's because top gives different data from ps (which is actually true - ps gives average cpu % over the whole lifetime of the process, top over the last five seconds). Maybe this needs changing? Regards Jiri Palecek ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
