[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190829222320.GC183862@google.com>
Date: Thu, 29 Aug 2019 18:23:20 -0400
From: Joel Fernandes <joel@...lfernandes.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: linux-kernel@...r.kernel.org, byungchul.park@....com,
Josh Triplett <josh@...htriplett.org>,
Lai Jiangshan <jiangshanlai@...il.com>,
linux-doc@...r.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
rcu@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
kernel-team@...roid.com
Subject: Re: [PATCH 5/5] rcu: Remove kfree_call_rcu_nobatch()
Hi Paul,
I think this is the only contentious patch preventing my resend of the
series, let me know what you think, I replied below:
On Wed, Aug 28, 2019 at 02:56:36PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 27, 2019 at 03:01:59PM -0400, Joel Fernandes (Google) wrote:
[snip]
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 12c17e10f2b4..c767973d62ac 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2777,8 +2777,10 @@ static void kfree_rcu_work(struct work_struct *work)
> > rcu_lock_acquire(&rcu_callback_map);
> > trace_rcu_invoke_kfree_callback(rcu_state.name, head, offset);
> >
> > - /* Could be possible to optimize with kfree_bulk in future */
> > - kfree((void *)head - offset);
> > + if (!WARN_ON_ONCE(!__is_kfree_rcu_offset(offset))) {
> > + /* Could be optimized with kfree_bulk() in future. */
> > + kfree((void *)head - offset);
> > + }
>
> This really needs to be in the previous patch until such time as Tiny RCU
> no longer needs the restriction.
I was only going by whatever is already committed to the -rcu dev branch. The
series is based on the -dev branch.
The original patch adding the kfree_rcu() batching is already merged into the
-rcu dev branch (that version just had 1 list, this series adds multiple
lists).
In the above diff, I just added the WARN_ON_ONCE() as extra checking for tree
RCU kfree batching. It has nothing to do with tiny RCU per-se. Should I
submit the WARN_ON_ONCE() as a separate patch then?
To prevent confusion, could you let me know if I am supposed to submitting
patches against a branch other than the dev branch?
> > rcu_lock_release(&rcu_callback_map);
> > cond_resched_tasks_rcu_qs();
> > @@ -2856,16 +2858,6 @@ static void kfree_rcu_monitor(struct work_struct *work)
> > spin_unlock_irqrestore(&krcp->lock, flags);
> > }
> >
> > -/*
> > - * This version of kfree_call_rcu does not do batching of kfree_rcu() requests.
> > - * Used only by rcuperf torture test for comparison with kfree_rcu_batch().
> > - */
> > -void kfree_call_rcu_nobatch(struct rcu_head *head, rcu_callback_t func)
> > -{
> > - __call_rcu(head, func);
> > -}
> > -EXPORT_SYMBOL_GPL(kfree_call_rcu_nobatch);
> > -
> > /*
> > * Queue a request for lazy invocation of kfree() after a grace period.
> > *
> > @@ -2885,12 +2877,6 @@ void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> > unsigned long flags;
> > struct kfree_rcu_cpu *krcp;
> >
> > - /* kfree_call_rcu() batching requires timers to be up. If the scheduler
> > - * is not yet up, just skip batching and do the non-batched version.
> > - */
> > - if (rcu_scheduler_active != RCU_SCHEDULER_RUNNING)
> > - return kfree_call_rcu_nobatch(head, func);
> > -
> > if (debug_rcu_head_queue(head)) {
> > /* Probable double kfree_rcu() */
> > WARN_ONCE(1, "kfree_call_rcu(): Double-freed call. rcu_head %p\n",
> > @@ -2909,8 +2895,15 @@ void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func)
> > krcp->head = head;
> >
> > /* Schedule monitor for timely drain after KFREE_DRAIN_JIFFIES. */
> > - if (!xchg(&krcp->monitor_todo, true))
> > - schedule_delayed_work(&krcp->monitor_work, KFREE_DRAIN_JIFFIES);
> > + if (!xchg(&krcp->monitor_todo, true)) {
> > + /* Scheduling the monitor requires scheduler/timers to be up,
> > + * if it is not, just skip it. An eventual kfree_rcu() will
> > + * kick it again.
> > + */
> > + if ((rcu_scheduler_active == RCU_SCHEDULER_RUNNING)) {
> > + schedule_delayed_work(&krcp->monitor_work, KFREE_DRAIN_JIFFIES);
> > + }
> > + }
>
> And this also needs to be in an earlier patch. Bisectability and all that!
>
> Are we really guaranteed that there will be an eventual kfree_rcu()?
> More of a worry for Tiny RCU than for Tree RCU, but still could be
> annoying for someone trying to debug a memory leak.
Same comment as above, the original patch adding the schedule_delayed_work()
is already merged into the -dev branch. This series is based on top of that.
The reason I had to rearrange &krcp->monitor_todo code above is because we no
longer have kfree_rcu_no_batch() which this patch removes.
thanks,
- Joel
Powered by blists - more mailing lists