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: Sat, 25 Jul 2009 00:22:51 -0500 From: Bill Gatliff <bgat@...lgatliff.com> 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 Subject: Re: report a bug about sched_rt Jamie Lokier wrote: > 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. > Useful perhaps, but an application design that explicitly communicates your desires to the scheduler will be more robust, even if it does seem more complex at the outset. I'm with Peter on this one. My impression of RT-bandwidth is that you shouldn't ever see it doing anything unless your system contains an error. In those situations, it's definitely a handy alternative to rebooting to get your shell back. But I don't think you want to build a system that depends on it, perhaps for no other reason than the fact that if RT-bandwidth doesn't make your system behave itself then you don't have a Plan B anymore. b.g. -- Bill Gatliff bgat@...lgatliff.com -- 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