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
| ||
|
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/
Powered by blists - more mailing lists