[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinifUTnjypY-h6Vv2qV9O7O4ZOFurxtrEr-3Rig@mail.gmail.com>
Date: Fri, 4 Jun 2010 12:56:16 +0200
From: Stijn Devriendt <highguy@...il.com>
To: Chris Mason <chris.mason@...cle.com>, Ingo Molnar <mingo@...e.hu>,
peterz@...radead.org, axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] reduce runqueue lock contention
On Thu, May 20, 2010 at 10:48 PM, Chris Mason <chris.mason@...cle.com> 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
--
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