[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101216175801.GB12841@redhat.com>
Date: Thu, 16 Dec 2010 18:58:01 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Chris Mason <chris.mason@...cle.com>,
Frank Rowand <frank.rowand@...sony.com>,
Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Mike Galbraith <efault@....de>, Paul Turner <pjt@...gle.com>,
Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 5/5] sched: Reduce ttwu rq->lock contention
On 12/16, Peter Zijlstra wrote:
>
> Then instead of locking the remote rq and activating the task, place
> the task on a remote queue, again using cmpxchg, and notify the remote
> cpu per IPI if this queue was empty to start processing its wakeups.
Interesting... I didn't actually read this patch yet, just a very
minor nit.
> +#ifdef CONFIG_SMP
> +static void ttwu_queue_remote(struct task_struct *p, int cpu)
> +{
> + struct task_struct *next = NULL;
> + struct rq *rq = cpu_rq(cpu);
> +
> + for (;;) {
> + struct task_struct *old = next;
> +
> + p->wake_entry = next;
> + next = cmpxchg(&rq->wake_list, old, p);
Somehow I was confused by initial "next = NULL", perhaps
struct rq *rq = cpu_rq(cpu);
struct task_struct *next = rq->wake_list;
makes a bit more sense.
Oleg.
--
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