linux-kernel - Re: behavior of hrtimers scheduled to expire in the past, SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4b6fba110810231038oe89539ex9b5ee28458257b5a@mail.gmail.com>
Date:	Thu, 23 Oct 2008 13:38:30 -0400
From:	"Daniel Rosenthal" <danielrosenthal@....org>
To:	"Dario Faggioli" <raistlin@...ux.it>
Cc:	"Thomas Gleixner" <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Peter Zijlstra" <peterz@...radead.org>
Subject: Re: behavior of hrtimers scheduled to expire in the past, SCHED_SPORADIC subtlety

On Thu, Oct 23, 2008 at 4:10 AM, Dario Faggioli <raistlin@...ux.it> wrote:
> First of all I've changed the interface from standard POSIX calls
> (sched_setscheduler, etc.) to the new API (sched_setscheduler2, etc.) as
> suggested in the LKML.

I was thinking about this, and I'm not convinced that this is actually
a good idea. It seems the only POSIX call that arguably needs a dual
is sched_getparam(). Every other function (sched_setscheduler() and
sched_setparam()) should be able to determine from the policy the
appropriate structure to copy from user space. For example, if the
policy is SCHED_SPORADIC, the function knows it needs to copy a new
sched_param structure from user space, including
sched_ss_low_priority, etc., and otherwise it just copies an old
sched_param_legacy structure containing the single field struct
sched_priority. Considerable padding can also be added (making the
final structure 512 bytes or so) to sched_param for future
compatability so this change (hopefully) never has to be made again.

Of course, this would probably require re-coding
do_sched_setscheduler(), and I know this would break the convention of
Linux system call implementations where the user arguments are copied
from user space before any arguments are actually examined, but I
think it is worth it to minimize incompatibility with POSIX, since
after all the whole point of POSIX is to make programs portable and
not implementation specific. I understand such portability is at
conflict with the interest of backwards binary compatibility, but any
POSIX non-conformance should be minimized. In this particular case I
don't see why this can't be done by only adding sched_getparam2() (and
slightly modifying sched_getparam()) and not changing anything else.

> After that I discovered that dealing with poor precision in budget
> accounting (tick resolution) causes very big issues, especially if
> budget and period are very short, and I had to rethink the algorithm and
> the code again to cope with this (and no, hrtick does not help, not so
> much at least!). :-(

Are you talking about a situation in which the platform cannot provide
high-resolution ticks, or do you mean something else?

> All this took very long time, much more than what I expected, but now
> it's ready... I'm just testing it with some corner cases I have been
> able to figure out and, more interestingly, I'm trying to establish a
> meaningful comparison between the present throttling mechanism and the
> SCHED_SPORADIC group scheduling.

This is definitely an interesting issue. In the future it might be
better to model the entire rt-throttling mechanism as a periodic
server, and model group scheduling in the same way. This has been
proposed before by multiple people in real-time systems, including Rob
Davis and Alan Burns.

> In a short while (I hope) I'll send the patch again to you as well as to
> the ML, so that we can discuss about it being more informed. :-)

Thanks. This is very much appreciated :-).

> Also, I'm going to present this work at the next RealTime Linux
> Workshop, next week, in Mexico... Are you attending?

Unfortunately not. Good luck on your presentation though :-).

Daniel

-----------------------------------------------
Daniel Rosenthal
Florida State University
http://ww2.cs.fsu.edu/~rosentha/

Sporadic Server stuff:
http://ww2.cs.fsu.edu/~rosentha/cop5641/
http://ww2.cs.fsu.edu/~rosentha/cop5641/modifications.php
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/