On Fri, Jan 17, 2020 at 08:34:58PM -0800, Paul E. McKenney wrote:
> On Fri, Jan 17, 2020 at 09:34:34PM -0500, Joel Fernandes wrote:
> > On Fri, Jan 17, 2020 at 03:17:56PM -0800, Paul E. McKenney wrote:
> > [...]
> > > But rcutorture already has tests for RCU priority boosting. Or are those
> > > failing in some way?
> >
> > Yes there are tests, but I thought of just a simple experiment to study this.
> > Purely since it is existing RCU kernel code that I'd like to understand. And
> > me/Daniel are also looking into possibly using run-time / trace-based
> > verification some of these behaviors.
>
> The functionality of rcu_state.cbovld should make that more entertaining.
>
> But I would guess that the initial model would ignore memory footprint
> and just model RCU priority boosting as kicking in a fixed time after
> the beginning of the grace period.
>
> Or do you guys have something else in mind?
>
> Thanx, Paul
>
> PS. Steve, yes, I do well remember our earlier discussions about readers
> inheriting priority from the highest-priority synchronize_rcu(). ;-)
To see the reason why RCU priority boosting does not work like that,
consider a (stupid but legal) situation with way more tasks like this
than the system can handle:
for (;;) {
cond_resched();
p = kmalloc(sizeof(*p), GFP_ATOMIC);
if (!p)
continue;
rcu_read_lock();
kfree(&p->rh, my_func);
rcu_read_unlock(;
}
Nothing is ever waiting on the RCU grace period, so there is no natural
place for priority to be inherited from.
But the current RCU priority boosting works just fine in this situation,
at least assuming rcutree.kthread_prio is set suitably. And if it is
not working fine in some other situation, it would be good for someone
to let me in on the secret. ;-)
Thanx, Paul
