On Mon, Oct 31, 2016 at 07:52:40PM -0700, Paul E. McKenney wrote: > On Tue, Nov 01, 2016 at 04:36:54AM +0200, Michael S. Tsirkin wrote: > > On Mon, Oct 31, 2016 at 07:19:41PM -0700, Paul E. McKenney wrote: > > > On Tue, Nov 01, 2016 at 12:37:04AM +0200, Michael S. Tsirkin wrote: > > > > On Mon, Oct 31, 2016 at 11:15:43AM -0700, Paul E. McKenney wrote: > > > > > On Mon, Oct 31, 2016 at 06:38:52PM +0100, Sebastian Andrzej Siewior wrote: > > > > > > On 2016-10-16 04:28:46 [-0700], Paul E. McKenney wrote: > > > > > > > If the relevant maintainers are OK with that, I am OK with it as long > > > > > > > as it is non-default (at least to begin with) and does not introduce > > > > > > > additional Kconfig questions. My guess is that a boot parameter would > > > > > > > work best, but something to discuss. > > > > > > > > > > > > Okay. For me to summary: > > > > > > - we want rcu_normal_after_boot=1 on -RT via CONFIG_PREEMPT_RT_FULL > > > > > > > > > > That would be good. > > > > > > > > > > > - this makes synchronize_rcu_expedited() behave like > > > > > > synchronize_rcu() and therefore I can drop all patches replacing > > > > > > synchronize_rcu_expedited() with synchronize_rcu(). > > > > > > > > > > And this would be a benefit. ;-) > > > > > > > > > > > - optionally it has been requested to make synchronize_rcu() behave like > > > > > > synchronize_rcu_expedited() on shutdown and kexec(). > > > > > > > > > > You can invoke rcu_unexpedite_gp() to force all subsequennt grace periods > > > > > to be expedited, but you do need to clear rcu_normal for this to have > > > > > effect. Right now, that means "WRITE_ONCE(rcu_normal, 0)", but I could > > > > > easily supply a formal API if you would prefer. Which you probably > > > > > would given that TINY_RCU doesn't have rcu_normal... > > > > > > > > > > > Did I miss understood / forgot something? > > > > > > > > > > It would not hurt to boot with rcu_expedited if boot speed is critical, > > > > > but I don't know whether or not this should be enabled by default. > > > > > > > > > > Thanx, Paul > > > > > > > > I don't know either but I'd like to know ATM it's expedited > > > > by default. > > > > > > In current mainline, no. That is, rcu_expedited=0 by default. > > > > > > Or am I missing the point of your question? > > > > > > Thanx, Paul > > > > That's true - what I meant is that adding and removing network devices > > happens on boot and calls synchronize_rcu_expedited, > > with the commit log explaining that this is done for speeding up boot > > and shutdown. > > The rcu_normal boot parameter will indeed nullify this optimization. > The boot parameters are normally dumped into dmesg, which should allow > determining when this has happened. But I do still feel like I am not > fully understanding your concern. > > Thanx, Paul I thought you asked whether people that care about boot time should just boot with rcu_expedited=1. I was trying to say that the fact net core calls expedited sync implies that many people care about boot time. Should rcu_normal_after_boot override rcu_expedited? I'm not sure what happens if you specify both ATM. -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
