lkml.org 
[lkml]   [2020]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2020-03-30 16:43    [W:0.044 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site