[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130206185213.GC2875@htj.dyndns.org>
Date: Wed, 6 Feb 2013 10:52:13 -0800
From: Tejun Heo <tj@...nel.org>
To: Hillf Danton <dhillf@...il.com>
Cc: Rusty Russell <rusty@...tcorp.com.au>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] stop_machine: wake up stopper thread lazily
On Wed, Feb 06, 2013 at 08:40:32PM +0800, Hillf Danton wrote:
> Ring no bell if the stopper thread is busy in handling enqueued works.
>
> Signed-off-by: Hillf Danton <dhillf@...il.com>
> ---
>
> --- a/kernel/stop_machine.c Wed Feb 6 20:05:44 2013
> +++ b/kernel/stop_machine.c Wed Feb 6 20:06:56 2013
> @@ -72,8 +72,10 @@ static void cpu_stop_queue_work(struct c
> spin_lock_irqsave(&stopper->lock, flags);
>
> if (stopper->enabled) {
> + int wakeup = list_empty(&stopper->works);
> list_add_tail(&work->list, &stopper->works);
> - wake_up_process(stopper->thread);
> + if (wakeup)
> + wake_up_process(stopper->thread);
Why does this matter? It shouldn't matter for correctness. Is it
meant to be an optimization? Is it something worth optimizing? We
hardly ever have contention on cpu stoppers after all and we
shouldn't.
--
tejun
--
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