2010-06-04 10:56:19

by Stijn Devriendt

[permalink] [raw]
Subject: Re: [PATCH RFC] reduce runqueue lock contention

On Thu, May 20, 2010 at 10:48 PM, Chris Mason <[email protected]> wrote:
> I think we probably want to add a way to wait just for a little while as
> a more lightweight operation (less balancing etc) but this patch doesn't
> do that. ?It only tries to make the act of waking someone up less
> expensive by avoiding the runqueue lock when we're on a different CPU
> than the process we want to wake.
>
> I do this with a per-runqueue list and some cmpxchg tricks. ?Basically
> all the other CPUs will toss a given process they want to wakeup onto
> the destination per-runqueue list. ?Later on, when that runqueue is
> finding a new task to run, it processes the list in bulk.

I actually have the reverse lying around somewhere (even more broken, probably)
to allow nested wakeups from the scheduler.

The issue I want to tackle is waking up processes when others go to sleep.
This means try_to_wake_up() from inside the runqueue lock.

I used a simple per_cpu taskqueue where tasks are put on when waking
during schedule(). At the end of schedule() I empty the list and reschedule
as one of the newly woken tasks may be higher prio.

I'm wondering if both approaches can be merged by checking this list before
and after every schedule().

Stijn


2010-06-04 12:00:41

by Peter Zijlstra

[permalink] [raw]
Subject: Re: [PATCH RFC] reduce runqueue lock contention

On Fri, 2010-06-04 at 12:56 +0200, Stijn Devriendt wrote:

> The issue I want to tackle is waking up processes when others go to sleep.
> This means try_to_wake_up() from inside the runqueue lock.


Tejun did something for that:

http://lkml.org/lkml/2010/5/13/136

2010-06-05 09:37:13

by Stijn Devriendt

[permalink] [raw]
Subject: Re: [PATCH RFC] reduce runqueue lock contention

On Fri, Jun 4, 2010 at 2:00 PM, Peter Zijlstra <[email protected]> wrote:
> On Fri, 2010-06-04 at 12:56 +0200, Stijn Devriendt wrote:
>
>> The issue I want to tackle is waking up processes when others go to sleep.
>> This means try_to_wake_up() from inside the runqueue lock.
>
>
> Tejun did something for that:
>
> ?http://lkml.org/lkml/2010/5/13/136
>
>
>

The difference with what I have is that Tejun's threads are guaranteed
to be local
and on the same CPU/runqueue avoiding runqueue deadlocks. My code can be
used to wake up any thread as I basically defer waking up untill after
the runqueue
lock is released.