Re: [RFC PATCH 06/15] nohz_task: Keep the tick if rcu needs it

[Frederic Weisbecker]

On Mon, Dec 20, 2010 at 05:12:59PM -0700, Jonathan Corbet wrote:
> On Tue, 21 Dec 2010 00:49:38 +0100
> Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> 
> > Nope, the new config can only be built after [RFC PATCH 11/15] x86: Nohz task support
> > 
> > I know I split up the patches in some unusual way but I did that on purpose:
> > I wanted to have a finegrained patchset so that it's more reviewable than a big
> > "core support" - "arch support" dual patch based style.
> > 
> > But I ensured the new config can not be enabled before it's entirely buildable
> > and has no known bugs.
> 
> Which is a nice thought (it helped me to understand the patches - article
> forthcoming)

Oh great :)

> but there is a downside: if anybody tries to bisect a
> problem, they'll end up at #11.  This stuff is sufficiently tricky that it
> would be nice to be able to bisect a little closer to the patch which
> actually introduced a bug.


Yeah indeed. I think I could split that up another way while keeping the fine
grained progression (if any).

I could enable the interface and CONFIG a bit sooner, once we have the support
for tick stop and restart handling basic things like woken up tasks and rcu
pending works checks.
And then handle the rcu extended grace periods in userspace later.
Because it works without, the nohz task would just be regularly interrupted by
rcu IPIs to note the quiescent states.

There are lots of changes to be done anyway, so I'm sure there will be enough
new takes of this for me to train more patchset split-up flavours ;-)
--
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/