| 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
| ||
|
Message-Id: <1248451279.6987.138.camel@twins> Date: Fri, 24 Jul 2009 18:01:19 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Jamie Lokier <jamie@...reable.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 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 ;-) -- 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