Re: [RFC][PATCH 12/13] stop_machine: Remove lglock
From: Peter Zijlstra
Date: Fri Jun 26 2015 - 08:32:34 EST
On Thu, Jun 25, 2015 at 07:51:46AM -0700, Paul E. McKenney wrote:
> > So please humour me and explain how all this is far more complicated ;-)
>
> Yeah, I do need to get RCU design/implementation documentation put together.
>
> In the meantime, RCU's normal grace-period machinery is designed to be
> quite loosely coupled. The idea is that almost all actions occur locally,
> reducing contention and cache thrashing. But an expedited grace period
> needs tight coupling in order to be able to complete quickly. Making
> something that switches between loose and tight coupling in short order
> is not at all simple.
But expedited just means faster, we never promised that
sync_rcu_expedited is the absolute fastest primitive ever.
So I really should go read the RCU code I suppose, but I don't get
what's wrong with starting a forced quiescent state, then doing the
stop_work spray, where each work will run the regular RCU tick thing to
push it forwards.
>From my feeble memories, what I remember is that the last cpu to
complete a GP on a leaf node will push the completion up to the next
level, until at last we've reached the root of your tree and we can
complete the GP globally.
To me it just makes more sense to have a single RCU state machine. With
expedited we'll push it as fast as we can, but no faster.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/