[LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[Petr Vorel]

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?

Kind regards,
Petr

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

Re: [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[Cyril Hrubis]

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.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[Cyril Hrubis]

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.

-- 
Cyril Hrubis
chrubis@suse.cz

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

Re: [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[Cyril Hrubis]

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

Re: [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value

[Jiri Bohac]

Hi,

On Tue, Jul 18, 2023 at 04:37:17PM +0200, Cyril Hrubis wrote:
> > > > 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

makes sense to me; good catch!

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, Prague, Czechia


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