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, 28 Aug 2008 18:29:38 +0200 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: Steven Rostedt <rostedt@...dmis.org> Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org, Stefani Seibold <stefani@...bold.net>, Dario Faggioli <raistlin@...ux.it>, Nick Piggin <nickpiggin@...oo.com.au>, Max Krasnyansky <maxk@...lcomm.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Thomas Gleixner <tglx@...utronix.de> Subject: Re: [PATCH 6/6] sched: disabled rt-bandwidth by default On Thu, 2008-08-28 at 12:15 -0400, Steven Rostedt wrote: > > On Thu, 28 Aug 2008, Peter Zijlstra wrote: > > > On Thu, 2008-08-28 at 10:15 -0400, Steven Rostedt wrote: > > > > > My biggest concern about adding a limit to FIFO is that an RT developer > > > would spend weeks trying to debug their system wondering why their > > > planned CPU RT hog, is being preempted by a non-RT task. > > > > > > For this, if this time limit does kick in, we should at the very least > > > print something out to let the user know this happened. After all, this > > > is more of a safety net anyway, and if we are hitting the limit, the > > > user should be notified. Perhaps even tell the user that if this > > > behaviour is expected, to up the sysctl <var> by more. > > > > Should be easy enough to do - > > > > > Peter, another question. Is this limit for a single RT task running, or > > > all RT tasks. I'm assuming here that it is a single RT task. If you have > > > 20 RT tasks all running, would this let non RT tasks in? In that case, > > > this could be even a bigger issues. > > > > No its not per task. Its per group (and trivially the !group case is one > > group). > > Does this mean, if I have 100 RT tasks, that will together run for 10secs > secs, they will only run for 9.5secs? > > This looks like an even bigger issue. Now we don't have one RT FIFO CPU > hog, we are now hitting 100 RT FIFO tasks that try to get a bunch done in > 10 secs. Yes. But say you were doing rate monotonic scheduling (as is not uncommonly done on top of SCHED_FIFO) then you could not get 100% cpu utilisation anyway, as RMS has a ~69% utility bound. -- 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