[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090426112717.GE10391@elte.hu>
Date: Sun, 26 Apr 2009 13:27:17 +0200
From: Ingo Molnar <mingo@...e.hu>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, davem@...emloft.net,
dada1@...mosbay.com, zbr@...emap.net, jeff.chua.linux@...il.com,
paulus@...ba.org, laijs@...fujitsu.com, jengelh@...ozas.de,
r000n@...0n.net, benh@...nel.crashing.org,
mathieu.desnoyers@...ymtl.ca
Subject: Re: [PATCH RFC] v2 expedited "big hammer" RCU grace periods
* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> Second cut of "big hammer" expedited RCU grace periods, but only
> for rcu_bh. This creates another softirq vector, so that entering
> this softirq vector will have forced an rcu_bh quiescent state (as
> noted by Dave Miller). Use smp_call_function() to invoke
> raise_softirq() on all CPUs in order to cause this to happen.
> Track the CPUs that have passed through a quiescent state (or gone
> offline) with a cpumask.
hm, i'm still asking whether doing this would be simpler via a
reschedule vector - which not only is an existing facility but also
forces all RCU domains through a quiescent state - not just bh-RCU
participants.
Triggering a new softirq is in no way simpler that doing an SMP
cross-call - in fact softirqs are a finite resource so using some
other facility would be preferred.
Am i missing something?
Ingo
--
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