lkml.org 
[lkml]   [2020]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 09/16] rcu/tree: Maintain separate array for vmalloc ptrs
> > > 
> > > 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.

> > > But again, either way, future work as far as this series is concerned.
> > >
> > What do you mean: is concerned?
>
> Apologies for the strange English. How about this?
>
> "This series is OK as is. Any comments above did not prevent me from
> taking these patches, but instead discuss possible future work."
>
That is perfectly clear to me :)

> > We are planning to implement kfree_rcu() to be integrated directly into
> > SLAB: SLAB, SLUB, SLOB. So, there are plenty of future work :)
>
> And I am glad that this is still the goal. ;-)
>
:)

--
Vlad Rezki

\
 
 \ /
  Last update: 2020-06-18 20:36    [W:1.181 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site