[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFw21PK8gBMNk_7kp1MmJoEsRyvPx+qaXSgwLFX2UN793g@mail.gmail.com>
Date: Fri, 6 Feb 2015 08:02:41 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Bruno Prémont <bonbons@...ux-vserver.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Ingo Molnar <mingo@...nel.org>,
Peter Hurley <peter@...leysoftware.com>,
Davidlohr Bueso <dave@...olabs.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ilya Dryomov <ilya.dryomov@...tank.com>,
Mike Galbraith <umgwanakikbuti@...il.com>,
Oleg Nesterov <oleg@...hat.com>
Subject: Re: Linux 3.19-rc5
On Fri, Feb 6, 2015 at 3:50 AM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> Also, set_current_state(TASK_RUNNING) is almost always pointless, nobody
> cares about that barrier, so make it go away.
I'd rather not mix this with the patch, and wonder if we should just
do that globally with some preprocessor magic. We do have a fair
number of "set_current_state(TASK_RUNNING)" and at least for the
*documented* reason for the memory barrier, all of them could/should
be barrier-less.
So something like
if (__is_constant_p(state) && state == TASK_RUNNING)
tsk->state = state;
else
set_mb(tsk->state, state);
might be more general solution than randomly doing one at a time when
changing code around it..
Linus
--
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