Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1167508

Re: call_rcu from trace_preempt

Show key headers only | View raw

On Wed, Jun 17, 2015 at 04:58:48PM -0700, Alexei Starovoitov wrote:
> On 6/17/15 2:36 PM, Paul E. McKenney wrote:
> >Well, you do need to have something in each element to allow them to be
> >tracked.  You could indeed use llist_add() to maintain the per-CPU list,
> >and then use llist_del_all() bulk-remove all the elements from the per-CPU
> >list.  You can then pass each element in turn to kfree_rcu().  And yes,
> >I am suggesting that you open-code this, as it is going to be easier to
> >handle your special case then to provide a fully general solution.  For
> >one thing, the general solution would require a full rcu_head to track
> >offset and next.  In contrast, you can special-case the offset.  And
> >ignore the overload special cases.
> 
> yes. all makes sense.
> 
> > Locklessly enqueue onto a per-CPU list, but yes.  The freeing is up to
> 
> yes. per-cpu llist indeed.
> 
> > you -- you get called just before exit from __call_rcu(), and get to
> > figure out what to do.
> >
> > My guess would be if not in interrupt and not recursively invoked,
> > atomically remove all the elements from the list, then pass each to
> > kfree_rcu(), and finally let things take their course from there.
> > The llist APIs look like they would work.
> 
> Above and 'just before the exit from __call_rcu()' part of suggestion
> I still don't understand.
> To avoid reentry into call_rcu I can either create 1 or N new kthreads
> or work_queue and do manual wakeups, but that's very specialized and I
> don't want to permanently waste them, so I'm thinking to llist_add into
> per-cpu llists and do llist_del_all in rcu_process_callbacks() to take
> them from these llists and call kfree_rcu on them.

Another option is to drain the lists the next time you do an allocation.
That would avoid hooking both __call_rcu() and rcu_process_callbacks().

							Thanx, Paul

> The llist_add part will also do:
> if (!rcu_is_watching()) invoke_rcu_core();
> to raise softirq when necessary.
> So at the end it will look like two phase kfree_rcu.
> I'll try to code it up and see it explodes :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: call_rcu from trace_preempt Alexei Starovoitov <ast@plumgrid.com> - 2015-06-16 03:20 +0200
  Re: call_rcu from trace_preempt Alexei Starovoitov <ast@plumgrid.com> - 2015-06-16 19:30 +0200
    Re: call_rcu from trace_preempt Steven Rostedt <rostedt@goodmis.org> - 2015-06-16 19:40 +0200
    Re: call_rcu from trace_preempt "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-17 22:40 +0200
      Re: call_rcu from trace_preempt Alexei Starovoitov <ast@plumgrid.com> - 2015-06-17 23:00 +0200
        Re: call_rcu from trace_preempt "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-17 23:40 +0200
          Re: call_rcu from trace_preempt Alexei Starovoitov <ast@plumgrid.com> - 2015-06-18 02:00 +0200
            Re: call_rcu from trace_preempt "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-18 02:30 +0200
  Re: call_rcu from trace_preempt "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-16 19:50 +0200
    Re: call_rcu from trace_preempt Steven Rostedt <rostedt@goodmis.org> - 2015-06-16 21:00 +0200
      Re: call_rcu from trace_preempt "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-16 21:30 +0200
        Re: call_rcu from trace_preempt Steven Rostedt <rostedt@goodmis.org> - 2015-06-16 21:30 +0200
          Re: call_rcu from trace_preempt "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-06-16 21:40 +0200

csiph-web