linux-kernel - Re: report a bug about 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:	Sat, 25 Jul 2009 14:33:21 +0200
From:	Raistlin <raistlin@...ux.it>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	sen wang <wangsen.linux@...il.com>, mingo@...e.hu,
	akpm@...ux-foundation.org, kernel@...ivas.org, npiggin@...e.de,
	arjan@...radead.org, linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org,
	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: report a bug about sched_rt

On Sat, 2009-07-25 at 00:30 +0100, Jamie Lokier wrote:
> > Unpredictable calculation times can be dealt with on the application
> > design level, for example using techniques such as outlined here:
> > 
> >   http://feanor.sssup.it/~faggioli/papers/OSPERT-2009-dlexception.pdf
> > 
> > These really are things you should know about before writing an RT
> > application ;-)
> 
> Certainly those things can be used, if you are really serious about RT
> behaviour.
Well... True... But not that much! :-)

>   They are quite complex.
> 
Agree... But it's just at its start, still working and trying to improve
it...

> For simple things like "try to keep the buffer to my DVD writer full"
> (no I don't know how much CPU that requires - it's a kind of "best
> effort but try very hard!"), it would be quite useful to have
> something like RT-bandwidth which grants a certain percentage of time
> as an RT task, and effectively downgrades it to SCHED_OTHER when that
> time is exceeded to permit some fairness with the rest of the system.
> 
Well, agree, again. If you want something very useful, you need the
combination of the two: user space techniques and kernel space support.

The mechanism described in the paper, work at its best if ran on top of
the proper scheduling policies/framework... And the rt-throttling
mechanism which is currently in place --or some improvements of it--
could definitely be one of those.

> You can do that in userspace using the techniques in the PDF, and I
> have looked at such techniques many years ago (2.2 days!), but the
> same could be said about RT-bandwidth.  But it's much easier to just
> set a kernel parameter.
> 
The aim of the mechanism was not to move RT to userspace, forgetting
about kernel support... Believe me: we are way far from that! :-)

As said, the point is trying to provide the user to specify some
--typically-- real-time characteristics of its apps, and have them
enforced somehow.

I don't think comparing kernel-space throttling with our user space
deadline/wcet violation notification is the right thing to do, since
they have very different objective, actually!

Throttling is aimed at limiting the bandwidth of real-time apps (or
groups of them) without the need of them to be aware of that.
Our exception based mechanism is aimed at giving the application
developer the capability of being aware of exactly such!

So, different tools for different goals, I think, which however could
work together, if needed...

I hope it would not seem I'm trying to push our mechanism over
anything... Just trying to clarify a little bit why we conceived it and
how it works. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

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