lkml.org 
[lkml]   [2009]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] don't preempt not TASK_RUNNING tasks

* Miklos Szeredi <miklos@szeredi.hu> wrote:

> On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> > On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> > > Ingo,
> > >
> > > I tested this one, and I think it makes sense in any case as an
> > > optimization. It should also be good for -stable kernels.
> > >
> > > Does it look OK?
> >
> > The idea is good, but there is a risk of preemption latencies here. Some
> > code paths aren't real quick between setting ->state != TASK_RUNNING and
> > calling schedule.
> >
> > [ Both quick: as in O(1) and few instructions ]
> >
> > So if we're going to do this, we'd need to audit all such code paths --
> > and there be lots.
>
> Oh, yes.
>
> In a random sample the most common pattern is something like this:
>
> spin_lock(&some_lock);
> /* do something */
> set_task_state(TASK_SOMESLEEP);
> /* do something more */
> spin_unlock(&some_lock);
> schedule();
> ...
>
> Which should only positively be impacted by the change. But I can
> imagine rare cases where it's more complex.

I'd suggest spin_unlock_no_resched() and task_unlock_no_resched()
instead of open-coding preempt-disable sequences.

> > The first line of attack for this problem is making
> > wait_task_inactive() sucks less, which shouldn't be too hard,
> > that unconditional 1 jiffy sleep is simply retarded.
>
> I completely agree. However, I'd like to have a non-invasive
> solution that can go into current and stable kernels so UML users
> don't need to suffer any more.

Agreed. task_unlock_no_resched() should do that i think.

Ingo


\
 
 \ /
  Last update: 2009-03-20 11:57    [W:0.048 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site