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

[Jan S. <jst...@re...>]

----- Original Message -----
> From: ch...@su...
> To: "Jan Stancek" <jst...@re...>
> Cc: "Zeng Linggang" <zen...@cn...>, "Drew Jones" <dr...@re...>, ltp...@li...
> Sent: Tuesday, 15 October, 2013 3:55:33 PM
> Subject: Re: [LTP] [PATCH] getrusage/getrusage04.c: Fix factor_nr = 1 ->	factor_nr = 5
> 
> 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...

Drew (from xen team) mentioned something along these lines as well.

Do we have some simple way to detect that test is running on xen (dom0/domU),
so we could end test with TCONF in that case?

Regards,
Jan

> 
> --
> Cyril Hrubis
> ch...@su...
>