From: Jiri Bohac <jbohac@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value
Date: Wed, 19 Jul 2023 11:28:47 +0200 [thread overview]
Message-ID: <ZLesz+hBcRGh1XOh@dwarf.suse.cz> (raw)
In-Reply-To: <ZLajnVugi-F3Lx_U@yuki>
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
prev parent reply other threads:[~2023-07-19 9:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 11:40 [LTP] sched_rr_get_interval01 depends on particular CONFIG_HZ value Petr Vorel
2023-07-18 13:48 ` Cyril Hrubis
2023-07-18 14:04 ` Cyril Hrubis
2023-07-18 14:37 ` Cyril Hrubis
2023-07-19 9:28 ` Jiri Bohac [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZLesz+hBcRGh1XOh@dwarf.suse.cz \
--to=jbohac@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox