On Sun, Jun 12, 2022 at 07:47:10PM +0200, Paolo Bonzini wrote: > On 6/12/22 19:29, Paolo Bonzini wrote: > > On 6/12/22 18:40, Paul E. McKenney wrote: > > > > Do these reserved memory regions really need to be allocated separately? > > > > (For example, are they really all non-contiguous? If not, that is, if > > > > there are a lot of contiguous memory regions, could you sort the IORT > > > > by address and do one ioctl() for each set of contiguous memory > > > > regions?) > > > > > > > > Are all of these reserved memory regions set up before init is spawned? > > > > > > > > Are all of these reserved memory regions set up while there is only a > > > > single vCPU up and running? > > > > > > > > Is the SRCU grace period really needed in this case? (I freely confess > > > > to not being all that familiar with KVM.) > > > > > > Oh, and there was a similar many-requests problem with networking many > > > years ago. This was solved by adding a new syscall/ioctl()/whatever > > > that permitted many requests to be presented to the kernel with a single > > > system call. > > > > > > Could a new ioctl() be introduced that requested a large number > > > of these memory regions in one go so as to make each call to > > > synchronize_rcu_expedited() cover a useful fraction of your 9000+ > > > requests? Adding a few of the KVM guys on CC for their thoughts. > > Another question: how much can call_srcu() callbacks pile up these days? > I've always been a bit wary of letting userspace do an arbitrary number of > allocations that can only be freed after a grace period, but perhaps there's > a way to query SRCU and apply some backpressure? They can pile up as much as ever, especially if you have long-duration sleeping readers. But you could do the occasional srcu_barrier() to wait for all the preceding ones to get done. Maybe every 1000th call_srcu() or similar? Thanx, Paul