Re: [patch] don't preempt not TASK_RUNNING tasks

[Ingo Molnar]

* Miklos Szeredi <miklos@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/