> > 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@xxxxxxxxxxxxxxxxx> > (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
