Message-ID: <1407303693.5090.171.camel@marge.simpson.net>
Date:	Wed, 06 Aug 2014 07:41:33 +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 Tue, 2014-08-05 at 16:28 -0700, Sergey Oboguev wrote: 
> On Sun, Aug 3, 2014 at 2:56 AM, Mike Galbraith <umgwanakikbuti@...il.com> wrote:
> 
> > SCHED_NORMAL where priority escalation does not work as preemption proofing
> 
> Remember, DPRIO is not for lock holders only.
> 
> Using DPRIO within SCHED_NORMAL policy would make sense for an application that
> has "soft" time-urgent section where it believes strong protection
> from preemption
> is not really necessary, and just a greater claim to CPU time share would do,
> in cases where the application does not know beforehand if the section will be
> short or long, and in majority of cases is short (sub-millisecond), but
> occasionally can take longer.

Every single time that SCHED_NORMAL task boosts its priority (nice)
during a preemption, the math has already been done, vruntime has
already been adjusted.  The boat has already sailed, and your task is
waving from the dock.  All this does is waste cycles and add yet more
math to the done deal.  Sure, when it gets the CPU back, its usage will
be weighed differently, it will become more resistant to preemption, but
in no way immune.  There is nothing remotely deterministic about this,
making it somewhat of an oxymoron when combined with critical section.

Add group scheduling to the mix, and this becomes even more pointless.

> > what I see is a programmer using a mechanism designed
> > to initiate preemption arming his tasks with countermeasures to the very
> > thing he initiates.
> 
> I disagree. The exact problem is that it is not a developer who initiates the
> preemption, but the kernel or another part of application code that is unaware
> of other thread's condition and doing it blindly, lacking the information about
> the state of the thread being preempted and the expected cost of its preemption
> in this state. DPRIO is a way to communicate this information.

Nope, I'm still not buying.  It's a bad idea to play with realtime
classes/priorities blindly, if someone does that, tough titty.

What DPRIO clearly does NOT do is to describe critical sections to the
kernel.  If some kthread prioritizes _itself_ and mucks up application
performance, file a bug report, that kthread is busted.  Anything a user
or application does with realtime priorities is on them.

Stuffing a priority card up selected tasks sleeves does not describe
critical sections to the kernel, it only lets the programmer stymie
himself, some other programmer... or perhaps the user.

> > Deferred preempt seems to be what you want, but you
> > invented something very different.
> 
> "Simple" deferred preempt is one use case.
> 
> More complex case is "ranked" deferred preemption, when there are multiple
> contending contexts, and there is a need to express relative costs of
> victimizing one vs. another.

You didn't invent either of those.

Hm.  I don't even recall seeing the task pulling a card from its sleeve
checking to see if the other player didn't have a joker up its sleeve.

> > I'm just not seeing the beauty in your patch.
> 
> Perhaps I might have a dissenting sense of beauty.
> But then, it is not only about the beauty (which is subjective anyway), but
> even more so about the pudding.
> 
> Seriously though, it's really simple: the whole range of available remedies is
> divided across post-preemption solutions and preemption-avoidance solutions
> (and of course designing app structure for minimizing the contention in the
> first place, but for the sake of this discussion we can assume this had been
> done to the extent possible). Post-preemption solutions unavoidably incur cost
> (and a part of this cost is incurred even before the solution can be engaged).
> If this cost can be maintained insignificant for the given use case, great.
> However what do you propose to do with those use cases where it cannot? To tell
> a developer (or IT manager) "we do not care about your 5% or 20% losses, and if
> you do not like it, use another OS that would work better for you"? This would
> not sound too productive to me.

I didn't suggest ignoring of any problems.  I know full well that folks
doing Oracle/SAP stuff can in fact make prettier numbers using realtime
class.  I also know they can get themselves into trouble, those troubles
having inspired bugzilla to pull my chain.  I didn't say "go away", I
created a hack to _enable_ them to turn their pet piggies loose in god
mode.  I didn't try to disarm or dissuade them from aiming the rt pistol
at their own toes, I gave them toe-seeking bullets.

You're reading me entirely wrong, I'm not trying to discourage you from
inventing a better bullet, I just think this particular bullet is a dud.

-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