[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150701155815.GH3717@linux.vnet.ibm.com>
Date: Wed, 1 Jul 2015 08:58:15 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Josh Triplett <josh@...htriplett.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>, laijs@...fujitsu.com,
dipankar@...ibm.com, Andrew Morton <akpm@...ux-foundation.org>,
mathieu.desnoyers@...icios.com,
Thomas Gleixner <tglx@...utronix.de>, rostedt@...dmis.org,
dhowells@...hat.com, dvhart@...ux.intel.com, fweisbec@...il.com,
oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH RFC tip/core/rcu 0/5] Expedited grace periods encouraging
normal ones
On Wed, Jul 01, 2015 at 04:08:27PM +0200, Eric Dumazet wrote:
> > OK, I'll bite. Exactly what seems especially vile about it?
>
> Presumably we would need to convert everything to async model
> (call_rcu() and friends),
> but that is a long way to go...
>
> For example, synchronize_srcu_expedited() in kvm_set_irq_routing()
> really looks overkill.
But synchronize_srcu_expedited() is SRCU, and does not disturb the
rest of the system.
Don't get me wrong, if converting it to call_srcu() helps, why not?
But synchronize_srcu_expedited() isn't messing up HPC or real-time
workloads.
Thanx, Paul
--
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