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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 25 Jul 2009 00:30:57 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	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
Subject: Re: report a bug about sched_rt

Peter Zijlstra wrote:
> On Fri, 2009-07-24 at 16:40 +0100, Jamie Lokier wrote:
> > Peter Zijlstra wrote:
> > > If you're using the bandwidth throttle to control your RT tasks so as
> > > not to starve your SCHED_OTHER tasks, then I will call your system ill
> > > designed.
> > 
> > What mechanism should be used to avoid starving SCHED_OTHER tasks, in
> > the event there are unforeseen bugs or unpredictable calculation times
> > in an RT task?
> 
> For bugs the throttle works, like I said a well functioning system is
> not supposed to hit the throttle, obviously a bug precludes the well
> functioning qualification :-)
> 
> 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.  They are quite complex.

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.

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.

-- Jamie

--
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/