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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.