linux-kernel - Re: [PATCH RFC] sched: deferred set priority (dprio)

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1407593592.5156.330.camel@marge.simpson.net>
Date:	Sat, 09 Aug 2014 16:13:12 +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-09 at 01:38 -0700, Sergey Oboguev wrote: 
> On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith <umgwanakikbuti@...il.com> wrote:
> 
> > I see subversion of a perfectly functional and specified mechanism
> 
> Just wondering if the following line of thinking would sound just as much an
> anathema from your perspective or perhaps a bit less terrible...
> 
> Proceeding from the observations (e.g. https://lkml.org/lkml/2014/8/8/492) that
> representative critical section information is not pragmatically expressible at
> development time or dynamically collectable by the application at run time, the
> option still remains to put the weight of managing such information on the
> shoulders of the final link in the chain, the system administrator, providing
> him with application-specific guidelines and also with monitoring tools.
> 
> It might look approximately like this.
> 
> It might be possible to define the scheduling class or some other kind of
> scheduling data entity for the tasks utilizing preemption control. The tasks
> belonging to this class and having critical section currently active are
> preemptible by RT or DL tasks just like normal threads, however they are
> granted a limited and controlled degree of protection against preemption by
> normal threads, and also limited ability to urgently preempt normal threads on
> a wakeup.

Sure, a completely different scheduling class can implement whatever
semantics it wants, just has to be useful and not break the world. 

(spins lots of complexity)

> This is not suggest any particular interface of course, but just a crude sketch
> of a basic approach. I am wondering if you would find it more agreeable within
> your perspective than the use of RT priorities, or still fundamentally
> disagreeable.

Yes, the crux of my objection is the subversion in my view of RT.

> (Personally I am not particularly thrilled by the complexity that would have
> to be added and managed.)

(yeah, you described lots of that)

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