Re: [PATCH] rcu: Only pin GP kthread when full dynticks is actually used

[Paul E. McKenney]

On Sat, Jun 14, 2014 at 03:10:15PM +0200, Frederic Weisbecker wrote:
> On Sat, Jun 14, 2014 at 04:26:39AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 13, 2014 at 10:06:06PM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 14, 2014 at 01:39:36AM +0200, Frederic Weisbecker wrote:
> > > > On Fri, Jun 13, 2014 at 04:27:15PM -0700, Paul E. McKenney wrote:
> > 
> > [ . . . ]
> > 
> > > > > If I was to extend rcu_needs_cpu(), I would add a flag and another counter
> > > > > to the rcu_data structure.  If rcu_needs_cpu() saw the flag set and the
> > > > > counter equal to the current ->completed value, it would return true.
> > > > > 
> > > > > I already have the rcu_kick_nohz_cpu() in rcu_implicit_dynticks_qs(),
> > > > > so it is just a matter of also setting the flag and copying ->completed
> > > > > to the new counter at that point.  I currently get to this point if the
> > > > > CPU has managed to run for more than one jiffy without hitting either
> > > > > idle or userspace execution.  Fair enough?
> > > > 
> > > > Perfect for me!
> > > 
> > > One complication...  So if the grace period has gone on for a long time,
> > > and you are returning to kernel mode, RCU will need the scheduling-clock
> > > tick.  However, in that very same situation, if you are returning to
> > > idle or to NO_HZ_FULL userspace execution, RCU does -not- need the
> > > scheduling-clock tick set.
> > > 
> > > One way I could do this is to have rcu_needs_cpu() return three values:
> > > Zero for RCU doesn't need a scheduling-clock tick for any reason,
> > > one if RCU needs a scheduling-clock tick only if returning to kernel
> > > mode, and two if RCU unconditionally needs the scheduling-clock tick.
> > > Would that work, or is there a better approach?
> > 
> > You know, it just feels like RCU -should- be able to solve this
> > internally.
> 
> Right, I should have read all emails before answering :)
> 
> > So if determining that you are returning to kernel mode is
> > at all inconvenient, give me a couple days to think this through.
> 
> Right so context_tracking_in_user() is probably what you need. Its semantics
> are:
> 
> 1) If we are in syscall or exception, it says we are in the kernel
> 2) If we are in interrupt, it says where we return (kernel or userspace).
> 
> Or course that's all subject to tiny error margin (soft versus hard userspace
> detection) but that shouldn't matter much as even with true hard detection,
> things can change quickly.

So there is an impressionistic painting of RCU inside my head.  And in
one corner, there is something that might be a dog.  If it really is a
dog, or can be convinced to become one, perhaps it can herd the sheep
in the middle of the painting.  At least they look sort of like sheep.
They might instead be rainclouds.  Or powdered-wig-wearing barristers.
Of course, in the latter case, introducing them to the dog might be
worthwhile just for sheer entertainment value.

Anyway, I am heading out to the gym.  Perhaps a few gym sessions and
a couple of sleep cycles will convert the painting to useful code.
This approach has worked well for me many times over the decades, so
here is hoping that it does again.

Apologies for the twisted metaphor, but you did ask!  Even if only
implicitly.  ;-)

							Thanx, Paul

--
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/