Re: [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[Cyril Hrubis <chrubis@suse.cz>]

Hi!
> > > sched_rr_get_interval01.c depends on particular CONFIG_HZ value.
> > > Recent change in openSUSE kernel from the default 250 to 300 breaks it:
> > > 
> > > sched_rr_get_interval01.c:57: TPASS: sched_rr_get_interval() passed
> > > sched_rr_get_interval01.c:64: TPASS: Time quantum 0s 99999990ns
> > > sched_rr_get_interval01.c:72: TFAIL: /proc/sys/kernel/sched_rr_timeslice_ms != 100 got 90
> > > sched_rr_get_interval01.c:57: TPASS: sched_rr_get_interval() passed
> > > sched_rr_get_interval01.c:64: TPASS: Time quantum 0s 99999990ns
> > > sched_rr_get_interval01.c:72: TFAIL: /proc/sys/kernel/sched_rr_timeslice_ms != 100 got 90
> > > 
> > > According to kernel/Kconfig.hz CONFIG_HZ can have various values (100, 250, 300,
> > > 1000). Should we adapt the test to expect any of these? Or should we require
> > > kernel config to read CONFIG_HZ value and check for correct value?
> > 
> > We had the same problem with getrusage04.c, see the
> > guess_timer_resolution() function there.
> 
> However in the case of sched_rr_get_interval() both values are supposed
> to be in seconds. The sched_rr_get_interval() fills in a timespec and
> the proc file is in miliseconds. As far as I can tell we actually
> compare apples to apples in the test and not oranges and apples.

So I suppose that this is just rounding error in kernel.

We do have RR_TIMESLICE defined as:

include/linux/sched/rt.h:

#define RR_TIMESLICE           (100 * HZ / 1000)

And we get the proc file from that by:

static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC / HZ) * RR_TIMESLICE;

If you put 300 you get:

(1000 / 300) * (100 * 300 / 1000)

Which in integer arithmetic is:

3 * 30 = 90

While the syscall acutally does a bit more work to get the numbers right
as it uses the timeslice (RR_TIMESLICE) in jiffies, which itself is
precise and converts that into timespec. We still getthe 99999990ns
instead of 100000000ns I suppose that is because jiffies_to_timespec64()
uses TICK_NSEC, which is more precise in integer arithmetics but still
rounded (we get 3333333 in the case of 300HZ and that multiplied by
RR_TIMESLICE is still 99999990).


Maybe the fix sould be to change the division as:

static int sysctl_sched_rr_timeslice = (MSEC_PER_SEC * RR_TIMESLICE) / HZ


Jiri any ideas on this, should I send a patch?

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp