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

[Frederic Weisbecker]

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.

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