[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140702172600.GR19379@twins.programming.kicks-ass.net>
Date: Wed, 2 Jul 2014 19:26:00 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, riel@...hat.com, mingo@...nel.org,
laijs@...fujitsu.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
dvhart@...ux.intel.com, fweisbec@...il.com, oleg@...hat.com,
sbw@....edu
Subject: Re: [PATCH RFC tip/core/rcu] Parallelize and economize NOCB kthread
wakeups
On Wed, Jul 02, 2014 at 10:08:38AM -0700, Paul E. McKenney wrote:
> As were others, not that long ago. Today is the first hint that I got
> that you feel otherwise. But it does look like the softirq approach to
> callback processing needs to stick around for awhile longer. Nice to
> hear that softirq is now "sane and normal" again, I guess. ;-)
Nah, softirqs are still totally annoying :-)
So I've lost detail again, but it seems to me that on all CPUs that are
actually getting ticks, waking tasks to process the RCU state is
entirely over doing it. Might as well keep processing their RCU state
from the tick as was previously done.
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists