Skip to contentSkip to conversation

questions about getrusage04

LTP Han Pingtian 2 participants 5 messages Dec 6, 2014 – Dec 8, 2014

lore
Share & tools
lore

Han Pingtian

author
#0 lore raw

Hey,

I cannot understand why udelta/sdelta > "1000+(BIAS_MAX*factor_nr)" is a problem. Could any expert give me a explain, please?

And looks like with this patch applied, it works well on powerpc:

testcases/kernel/syscalls/getrusage/getrusage04.c +1 -1
index 3640295..f118288 100644
@@ -92,7 +92,7 @@ int main(int argc, char *argv[])
        if (msg != NULL)
                tst_brkm(TBROK, NULL, "OPTION PARSING ERROR - %s", msg);
 
-#if (__powerpc__) || (__powerpc64__) || (__s390__) || (__s390x__)
+#if (__s390__) || (__s390x__)
        tst_brkm(TCONF, NULL, "This test is not designed for current system");
 #endif

although the initial git comment said that "accuracy on powerpc and s390x systems is always 10ms".

Thanks in advance!

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

#1 lore raw

Hi!

Quoted 2 lines

I cannot understand why udelta/sdelta > "1000+(BIAS_MAX*factor_nr)" is a problem. Could any expert give me a explain, please?

It tests timer precision for getrusage timers. If the timers are incremting by larger values than expected, something is wrong in kernel. The precision depends on CONFIG_HZ settings which is represented by the BIAS_MAX.

Quoted 1 line

And looks like with this patch applied, it works well on powerpc:

Can you please share the output of the testcase on ppc and ppc64? What is the expected timer granularity there?

Signature · 13 lines
Cyril Hrubis
[email protected]

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
author
#2 lore raw
Quoted 8 lines · Cyril Hrubis

Hi!

Quoted 2 lines

I cannot understand why udelta/sdelta > "1000+(BIAS_MAX*factor_nr)" is a problem. Could any expert give me a explain, please?

It tests timer precision for getrusage timers. If the timers are incremting by larger values than expected, something is wrong in kernel. The precision depends on CONFIG_HZ settings which is represented by the BIAS_MAX.

Where does the 1000 come from? If on a slow system, we need to increase the "factor_nr", right?

Quoted 6 lines
Quoted 2 lines

And looks like with this patch applied, it works well on powerpc:

Can you please share the output of the testcase on ppc and ppc64? What is the expected timer granularity there?

Looks like the granularity is 10000us:

getrusage04    0  TINFO  :  Expected timers granularity is 10000 us
getrusage04    0  TINFO  :  Using 1 as multiply factor for max [us]time increment (1000+10000us)!
getrusage04    0  TINFO  :  utime:          56us; stime:        1192us
getrusage04    0  TINFO  :  utime:          56us; stime:        2009us
getrusage04    0  TINFO  :  utime:          56us; stime:        4233us
getrusage04    0  TINFO  :  utime:        1227us; stime:        5243us
getrusage04    0  TINFO  :  utime:        1227us; stime:        8541us
getrusage04    0  TINFO  :  utime:        2072us; stime:        8741us
getrusage04    0  TINFO  :  utime:        2602us; stime:       11169us
getrusage04    0  TINFO  :  utime:        2743us; stime:       11747us
getrusage04    0  TINFO  :  utime:        2948us; stime:       12790us
getrusage04    0  TINFO  :  utime:        2948us; stime:       18118us
getrusage04    0  TINFO  :  utime:        2948us; stime:       18596us
getrusage04    0  TINFO  :  utime:        4458us; stime:       20030us
getrusage04    0  TINFO  :  utime:        4458us; stime:       20244us
getrusage04    0  TINFO  :  utime:        4458us; stime:       23432us
getrusage04    0  TINFO  :  utime:        5412us; stime:       24650us
getrusage04    0  TINFO  :  utime:        5412us; stime:       27273us
getrusage04    0  TINFO  :  utime:        6125us; stime:       27909us
getrusage04    0  TINFO  :  utime:        6125us; stime:       27911us
getrusage04    0  TINFO  :  utime:        6125us; stime:       28111us
getrusage04    0  TINFO  :  utime:        6235us; stime:       28513us
getrusage04    0  TINFO  :  utime:        6235us; stime:       28750us
getrusage04    1  TPASS  :  Test Passed

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

#3 lore raw

Hi!

Quoted 6 lines
Quoted 4 lines

It tests timer precision for getrusage timers. If the timers are incremting by larger values than expected, something is wrong in kernel. The precision depends on CONFIG_HZ settings which is represented by the BIAS_MAX.

Where does the 1000 come from? If on a slow system, we need to increase the "factor_nr", right?

The factor is set to 1 and it shouldn't needed to change that.

Quoted 23 lines
Quoted 5 lines
Quoted 1 line

And looks like with this patch applied, it works well on powerpc:

Can you please share the output of the testcase on ppc and ppc64? What is the expected timer granularity there?

Looks like the granularity is 10000us:

getrusage04    0  TINFO  :  Expected timers granularity is 10000 us
getrusage04    0  TINFO  :  Using 1 as multiply factor for max [us]time increment (1000+10000us)!
getrusage04    0  TINFO  :  utime:          56us; stime:        1192us
getrusage04    0  TINFO  :  utime:          56us; stime:        2009us
getrusage04    0  TINFO  :  utime:          56us; stime:        4233us
getrusage04    0  TINFO  :  utime:        1227us; stime:        5243us
getrusage04    0  TINFO  :  utime:        1227us; stime:        8541us
getrusage04    0  TINFO  :  utime:        2072us; stime:        8741us
getrusage04    0  TINFO  :  utime:        2602us; stime:       11169us
getrusage04    0  TINFO  :  utime:        2743us; stime:       11747us
getrusage04    0  TINFO  :  utime:        2948us; stime:       12790us
getrusage04    0  TINFO  :  utime:        2948us; stime:       18118us
getrusage04    0  TINFO  :  utime:        2948us; stime:       18596us
getrusage04    0  TINFO  :  utime:        4458us; stime:       20030us
getrusage04    0  TINFO  :  utime:        4458us; stime:       20244us
getrusage04    0  TINFO  :  utime:        4458us; stime:       23432us
Quoted 8 lines
getrusage04    0  TINFO  :  utime:        5412us; stime:       24650us
getrusage04    0  TINFO  :  utime:        5412us; stime:       27273us
getrusage04    0  TINFO  :  utime:        6125us; stime:       27909us
getrusage04    0  TINFO  :  utime:        6125us; stime:       27911us
getrusage04    0  TINFO  :  utime:        6125us; stime:       28111us
getrusage04    0  TINFO  :  utime:        6235us; stime:       28513us
getrusage04    0  TINFO  :  utime:        6235us; stime:       28750us
getrusage04    1  TPASS  :  Test Passed

Hmm, this looks like the granularity of the timer is much smaller than 10000us and it varies greatly between measurements. Is this CONFIG_NO_HZ system?

Signature · 13 lines
Cyril Hrubis
[email protected]

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
author
#4 lore raw
Quoted 42 lines · Cyril Hrubis

Hi!

Quoted 6 lines
Quoted 4 lines

It tests timer precision for getrusage timers. If the timers are incremting by larger values than expected, something is wrong in kernel. The precision depends on CONFIG_HZ settings which is represented by the BIAS_MAX.

Where does the 1000 come from? If on a slow system, we need to increase the "factor_nr", right?

The factor is set to 1 and it shouldn't needed to change that.

Quoted 23 lines
Quoted 5 lines
Quoted 1 line

And looks like with this patch applied, it works well on powerpc:

Can you please share the output of the testcase on ppc and ppc64? What is the expected timer granularity there?

Looks like the granularity is 10000us:

getrusage04    0  TINFO  :  Expected timers granularity is 10000 us
getrusage04    0  TINFO  :  Using 1 as multiply factor for max [us]time increment (1000+10000us)!
getrusage04    0  TINFO  :  utime:          56us; stime:        1192us
getrusage04    0  TINFO  :  utime:          56us; stime:        2009us
getrusage04    0  TINFO  :  utime:          56us; stime:        4233us
getrusage04    0  TINFO  :  utime:        1227us; stime:        5243us
getrusage04    0  TINFO  :  utime:        1227us; stime:        8541us
getrusage04    0  TINFO  :  utime:        2072us; stime:        8741us
getrusage04    0  TINFO  :  utime:        2602us; stime:       11169us
getrusage04    0  TINFO  :  utime:        2743us; stime:       11747us
getrusage04    0  TINFO  :  utime:        2948us; stime:       12790us
getrusage04    0  TINFO  :  utime:        2948us; stime:       18118us
getrusage04    0  TINFO  :  utime:        2948us; stime:       18596us
getrusage04    0  TINFO  :  utime:        4458us; stime:       20030us
getrusage04    0  TINFO  :  utime:        4458us; stime:       20244us
getrusage04    0  TINFO  :  utime:        4458us; stime:       23432us
Quoted 8 lines
getrusage04    0  TINFO  :  utime:        5412us; stime:       24650us
getrusage04    0  TINFO  :  utime:        5412us; stime:       27273us
getrusage04    0  TINFO  :  utime:        6125us; stime:       27909us
getrusage04    0  TINFO  :  utime:        6125us; stime:       27911us
getrusage04    0  TINFO  :  utime:        6125us; stime:       28111us
getrusage04    0  TINFO  :  utime:        6235us; stime:       28513us
getrusage04    0  TINFO  :  utime:        6235us; stime:       28750us
getrusage04    1  TPASS  :  Test Passed
Quoted 3 lines

Hmm, this looks like the granularity of the timer is much smaller than 10000us and it varies greatly between measurements. Is this CONFIG_NO_HZ system?

Yes, looks like it is:

% grep CONFIG_NO_HZ /boot/config-2.6.32-504.el6.ppc64 CONFIG_NO_HZ=y

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list