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. Thanx, Paul > > > > 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
