[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