On Mon, 20 Apr 2015 14:15:04 -0700 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote: > > On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote: > > > > > > The sysfs knob might be nice, but as far as I know nobody has been > > > complaining about it. > > > > > > Besides, we already have the rcutree.kthread_prio= kernel-boot parameter. > > > So how about if the Kconfig parameter selects either SCHED_OTHER > > > (the default) or SCHED_FIFO:1, and then the boot parameter can be used > > > to select other values. > > > > Hmm, what priority is this for anyway. To change the priority of the boost > > value at run time, do we only need to change the priority of the rcub > > threads? > > > > And the priority of the other rcu threads can change as well with a simple > > chrt? > > > > If that's the case, then we don't need a sysctl knob at all. > > For the grace-period kthreads and the boost kthread, that is the case. > It is also the case for the per-CPU kthreads that invoke RCU callbacks > for the non-offloaded RCU_BOOST configuration (and that replace all > softirq RCU work in -rt). > > So, should I just ditch all of the priority-setting within RCU and tell > users to just use chrt? Looks to me like all we need to do is tell people if they need a boost higher than the compiled in default (RCU_KTHREAD_PRIO), then chrt the priority of the rcub thread to the desired priority.
pgpReVixtRBn3.pgp
Description: OpenPGP digital signature
