On Fri, Jun 20, 2014 at 02:24:23PM -0700, j...@joshtriplett.org wrote:
> On Fri, Jun 20, 2014 at 12:12:36PM -0700, Paul E. McKenney wrote:
> > o Make cond_resched() a no-op for PREEMPT=y. This might well turn
> > out to be a good thing, but it doesn't help give RCU the quiescent
> > states that it needs.
>
> What about doing this, together with letting the fqs logic poke
> un-quiesced kernel code as needed? That way, rather than having
> cond_resched do any work, you have the fqs logic recognize that a
> particular CPU has gone too long without quiescing, without disturbing
> that CPU at all if it hasn't gone too long.
My next stop is to post the previous series, but with a couple of
exports and one bug fix uncovered by testing thus far, but after
another round of testing. Then I am going to take a close look at
this one:
o Push the checks further into cond_resched(), so that the
fastpath does the same sequence of instructions that the original
did. This might work well, but requires IPIs, which are not so
good for latencies on the remote CPU. It nevertheless might be a
decent long-term solution given that if your CPU is spending many
jiffies looping in the kernel, you aren't getting good latencies
anyway. It also has the benefit of allowing RCU to take advantage
of the implicit quiescent states of all cond_resched() calls,
and of eliminating the need for a separate cond_resched_rcu_qs()
and for RCU_COND_RESCHED_QS.
The one you call out is of course interesting as well. But there are
a couple of questions:
1. Why wasn't cond_resched() a no-op in CONFIG_PREEMPT to start
with? It just seems to obvious a thing to do for it to possibly
be an oversight. (What, me paranoid?)
2. When RCU recognizes that a particular CPU has gone too long,
exactly what are you suggesting that RCU do about it? When
formulating your answer, please give due consideration to the
implications of that CPU being a NO_HZ_FULL CPU. ;-)
Probably other questions as well, but those are the ones that come to
mind immediately.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
