Messages in this thread | | | Subject | Re: WARNING in __mmdrop | From | Jason Wang <> | Date | Fri, 26 Jul 2019 20:00:58 +0800 |
| |
On 2019/7/26 下午7:49, Michael S. Tsirkin wrote: > On Thu, Jul 25, 2019 at 10:25:25PM +0800, Jason Wang wrote: >> On 2019/7/25 下午9:26, Michael S. Tsirkin wrote: >>>> Exactly, and that's the reason actually I use synchronize_rcu() there. >>>> >>>> So the concern is still the possible synchronize_expedited()? >>> I think synchronize_srcu_expedited. >>> >>> synchronize_expedited sends lots of IPI and is bad for realtime VMs. >>> >>>> Can I do this >>>> on through another series on top of the incoming V2? >>>> >>>> Thanks >>>> >>> The question is this: is this still a gain if we switch to the >>> more expensive srcu? If yes then we can keep the feature on, >> >> I think we only care about the cost on srcu_read_lock() which looks pretty >> tiny form my point of view. Which is basically a READ_ONCE() + WRITE_ONCE(). >> >> Of course I can benchmark to see the difference. >> >> >>> if not we'll put it off until next release and think >>> of better solutions. rcu->srcu is just a find and replace, >>> don't see why we need to defer that. can be a separate patch >>> for sure, but we need to know how well it works. >> >> I think I get here, let me try to do that in V2 and let's see the numbers. >> >> Thanks
It looks to me for tree rcu, its srcu_read_lock() have a mb() which is too expensive for us.
If we just worry about the IPI, can we do something like in vhost_invalidate_vq_start()?
if (map) { /* In order to avoid possible IPIs with * synchronize_rcu_expedited() we use call_rcu() + * completion. */ init_completion(&c.completion); call_rcu(&c.rcu_head, vhost_finish_vq_invalidation); wait_for_completion(&c.completion); vhost_set_map_dirty(vq, map, index); vhost_map_unprefetch(map); }
?
> There's one other thing that bothers me, and that is that > for large rings which are not physically contiguous > we don't implement the optimization. > > For sure, that can wait, but I think eventually we should > vmap large rings.
Yes, worth to try. But using direct map has its own advantage: it can use hugepage that vmap can't
Thanks
| |