On Thu, Jun 18, 2020 at 12:03:59PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 18, 2020 at 08:34:48PM +0200, Uladzislau Rezki wrote:
> > > > >
> > > > > I suspect that he would like to keep the tracing.
> > > > >
> > > > > It might be worth trying the branches, given that they would be constant
> > > > > and indexed by "i". The compiler might well remove the indirection.
> > > > >
> > > > > The compiler guys brag about doing so, which of course might or might
> > > > > not have any correlation to a given compiler actually doing so. :-/
> > > > >
> > > > > Having a vfree_bulk() might well be useful, but I would feel more
> > > > > confidence in that if there were other callers of kfree_bulk().
> > > > >
> > > > Hmm... I think replacing that with vfree_bulk() is a good idea though.
> > >
> > > In other words, get rid of kfree_bulk() in favor of vfree_bulk()?
> > >
> > kfree_bulk() does not understand vmalloc memory. vfree_bulk() should
> > be implemented to release vmalloc's pointers. On i high level it will
> > be used the same way as kfree_bulk() but for vmalloc ptrs. only.
>
> Ah, I thought that you guys were proposing something that did bulk
> free of both kmalloc and vmalloc memory.
>
I see your point. We could introduce something like:
kvfree_bulk(slab_arra, vmalloc_array);
but i do not have a strong opinion here, even though i tend to
say that it would be odd. Having just vfree_bulk(), i think
would be enough, as a result the code will look like:
<snip>
trace_rcu_invoke_kfree_bulk_callback(
rcu_state.name, bkvhead[i]->nr_records,
bkvhead[i]->records);
if (i == 0)
kfree_bulk(bkvhead[i]->nr_records,
bkvhead[i]->records);
else
vfree_bulk(bkvhead[i]->nr_records,
bkvhead[i]->records);
<snip>
Matthew, what is your thought?
Thanks!
--
Vlad rezki
