Messages in this thread | | | Date | Thu, 23 Oct 2008 13:38:30 -0400 | From | "Daniel Rosenthal" <> | 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@linux.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
| |