| 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: Sun, 03 Aug 2014 11:56:16 +0200 From: Mike Galbraith <umgwanakikbuti@...il.com> To: Sergey Oboguev <oboguev.public@...il.com> Cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org, khalid.aziz@...cle.com Subject: Re: [PATCH RFC] sched: deferred set priority (dprio) On Sat, 2014-08-02 at 17:43 -0700, Sergey Oboguev wrote: > When reasoning about concurrency management it may be helpful to keep in mind > the fundamental perspective that the problem space and solution space in this > area are fragmented -- just as your message exemplifies as well, but it also > applies across the board to all other solution techniques. There is no > all-unifying solution that works in all use cases and for all purposes. I'm just not seeing the beauty in your patch. Ignoring SCHED_NORMAL where priority escalation does not work as preemption proofing, for realtime classes, what I see is a programmer using a mechanism designed to initiate preemption arming his tasks with countermeasures to the very thing he initiates. Deferred preempt seems to be what you want, but you invented something very different. As noted though, you don't have to convince me. The thing to do is chop your patch up into a nice reviewable series, and submit it. -Mike -- 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