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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Oct 2008 10:10:47 +0200
From:	Dario Faggioli <raistlin@...ux.it>
To:	Daniel Rosenthal <danielrosenthal@....org>
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 Wed, 2008-10-22 at 21:05 -0400, Daniel Rosenthal wrote:
> Darrio,
> Just to warn you, be careful that your SCHED_SPORADIC implementation
> deals with the above situation correctly.  
I know this is an issue, but anyway thank you very much for adding me to
this Cc. :-)

> Be careful to avoid this in your code because
> this is subtle and it took me a very long time to debug this
I know that feeling quite well!! :-P

> And regarding SCHED_SPORADIC, I am also working on SCHED_SPORADIC in
> 2.6.25. If I don't finish my RFC patch by the time you finish your
> final 2.6.27 patch, please let me know because I believe it would be
> beneficial for us to compare code before any final decisions are made
> (mine still isn't working well enough to compare yet).
Ok, this is how things are right now. Anyway, any comparison, discussion
and collaboration are more than welcome. :-D

I've almost rewritten almost all the code in order to fulfill Peter's
suggestions and to deal with some situations I did not consider in the
first implementation.

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.
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!). :-(

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.

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. :-)

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

Thanks again and Regards,
Dario

-- 
<<This happens because I choose it to happen!>>
(Raistlin Majere, DragonLance Chronicles -Dragons of Spring Drawning-)
----------------------------------------------------------------------
Dario Faggioli
GNU/Linux Registered User: #340657
Web: http://www.linux.it/~raistlin
Blog: http://blog.linux.it/raistlin
SIP Account: dario.faggioli@...proxy.wengo.fr or
             raistlin@...ga.net
Jabber Account: dario.faggioli@...ber.org/WengoPhone
GnuPG Key ID: 4DC83AC4
GnuPG Key Fingerprint: 2A78 AD5D B9CF A082 0836 08AD 9385 DA04 4DC8 3AC4

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)