Messages in this thread | | | From | Uladzislau Rezki <> | Date | Mon, 30 Mar 2020 16:42:27 +0200 | Subject | Re: [PATCH 6/7] rcu/tiny: support reclaim for head-less object |
| |
> > Hmm, Ok. So on -tiny, if there's any allocation failure ever, we immediately > revert to call_rcu(). I guess we could also create a regular (non-array) > queue for objects with an rcu_head and queue it on that (since it does not > need allocation) in case of array allocation failure, however that may not be > worth it. So this LGTM. Thanks! > > For entire series: > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> > (I will submit a follow-up to fix the tagging, please let me submit Vlad's > entire series with some patches on top -- I also did a bit of wordsmithing in > the commit messages of this series). > Thank you, Joel, for your review and help!
> > Loved the might_sleep() idea btw, I suppose if atomic context wants to do > kvfree_rcu(), then we could also have kfree_rcu() defer the kvfree_rcu() to > execute from a workqueue. Thoughts? We can then allow poor insomniacs from > calling this API :) > Not sure if i understand you correctly. Could you please <snip> some code for illustration?
As far as i understand, it should be done then synchronously. We can defer and queue some work to do it in worqueue context. But i am not sure how to proccess next coming request, i.e. busy waiting until we manage to push a new ptr. to free? But in that case it would not work if there is only one CPU available.
Thanks!
-- Vlad Rezki
| |