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 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. -- MST
