[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