Re: [LTP] [PATCH] getrusage/getrusage04.c: Fix factor_nr = 1 -> factor_nr = 5

[chrubis@suse.cz]

Hi!
> > When kernel is vmlinuz-2.6.18-371.el5xen, the case will fail.
> > But with vmlinuz-2.6.18-371.el5, it works well.
> 
> I'm seeing the same as you also with previous minor RHEL5 releases on dom0:
> 5.3 2.6.18-128.el5xen
> 5.6 2.6.18-238.el5xen
> 5.9 2.6.18-348.el5xen
> 5.10 2.6.18-371.el5xen
> 
> > Maybe the case is not suit for xen kernel.
> 
> It's possible, it doesn't look like regression to me so far.
> The systems are definitely not "slow" ones, and test can pass on bare-metal kernel. 

The problem with the test is that it tries to assert that granurality of
gerusage CPU time accounting is as good as possible. The granularity
itself depends on kernel config options, mainly on CONFIG_HZ. But as the
kernel compilation options are not exported (by running kernel) in any
reliable way the code I've added tries to guess them by side channel
(the CLOCK_REALTIME_COARSE resolution). If CLOCK_REALTIME_COARSE is not
supported it goes with 4ms which should correspond with CONFIG_HZ=250.

Now the accuracy on xen may be off for several reasons. It can have
CONFIG_HZ=100. Or xen may not be able to account virtual CPU time with
the same accuracy as on the real CPU...

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list