[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1292611264.2266.344.camel@twins>
Date: Fri, 17 Dec 2010 19:41:04 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
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 Fri, 2010-12-17 at 19:24 +0100, Peter Zijlstra wrote:
> > Even simpler. This can race with, say, __migrate_task() which does
> > deactivate_task + activate_task and temporary clears on_rq. Although
> > this is simple to fix, I think.
>
> Yes, another hole..
__migrate_task() is a tad special in that it should only migrate
runnable tasks, but of course we can have it preempted with ->state !=
TASK_RUNNING, which makes life interesting, but we can fix that by
including a PREEMPT_ACTIVE test in ttwu.
Other such callers are more straight fwd though:
rt_mutex_setprio()
set_user_nice()
sched_move_task()
__sched_setscheduler()
normalize_task()
none of those are fast-path operations, so it is quite doable to also
take the ->pi_lock there and fully serialize them.
--
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