From: Paolo Bonzini <pbonzini@redhat.com>
To: paulmck@kernel.org,
"zhangfei.gao@foxmail.com" <zhangfei.gao@foxmail.com>
Cc: Zhangfei Gao <zhangfei.gao@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
rcu@vger.kernel.org, Lai Jiangshan <jiangshanlai@gmail.com>,
Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Matthew Wilcox <willy@infradead.org>,
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
mtosatti@redhat.com, sheng.yang@intel.com
Subject: Re: Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow
Date: Sun, 12 Jun 2022 19:47:10 +0200 [thread overview]
Message-ID: <a3de4cf5-d760-1666-6b9c-f620c238453b@redhat.com> (raw)
In-Reply-To: <560f7d27-fe38-0db9-834a-50dda5fa6157@redhat.com>
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?
Paolo
next prev parent reply other threads:[~2022-06-12 17:47 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-11 16:32 Commit 282d8998e997 (srcu: Prevent expedited GPs and blocking readers from consuming CPU) cause qemu boot slow Zhangfei Gao
2022-06-11 16:59 ` Paul E. McKenney
2022-06-12 7:40 ` zhangfei.gao
2022-06-12 13:36 ` Paul E. McKenney
2022-06-12 14:59 ` zhangfei.gao
2022-06-12 16:20 ` Paul E. McKenney
2022-06-12 16:40 ` Paul E. McKenney
2022-06-12 17:29 ` Paolo Bonzini
2022-06-12 17:47 ` Paolo Bonzini [this message]
2022-06-12 18:51 ` Paul E. McKenney
2022-06-12 18:49 ` Paul E. McKenney
2022-06-12 19:23 ` Paolo Bonzini
2022-06-12 20:09 ` Paul E. McKenney
2022-06-13 3:04 ` zhangfei.gao
2022-06-13 3:57 ` Paul E. McKenney
2022-06-13 4:16 ` Paul E. McKenney
2022-06-13 6:55 ` zhangfei.gao
2022-06-13 12:18 ` Paul E. McKenney
2022-06-13 13:23 ` zhangfei.gao
2022-06-13 14:59 ` Paul E. McKenney
2022-06-13 20:55 ` Shameerali Kolothum Thodi
2022-06-14 12:19 ` Neeraj Upadhyay
2022-06-14 14:03 ` zhangfei.gao
2022-06-14 14:14 ` Neeraj Upadhyay
2022-06-14 14:57 ` zhangfei.gao
2022-06-14 14:17 ` Paul E. McKenney
2022-06-15 9:03 ` zhangfei.gao
2022-06-15 10:40 ` Neeraj Upadhyay
2022-06-15 10:50 ` Paolo Bonzini
2022-06-15 11:04 ` Neeraj Upadhyay
2022-06-18 3:07 ` zhangfei.gao
2022-06-20 7:50 ` Neeraj Upadhyay
2022-06-24 15:30 ` zhangfei.gao
2022-06-13 15:02 ` Shameerali Kolothum Thodi
2022-06-15 8:38 ` Marc Zyngier
2022-06-15 8:29 ` Marc Zyngier
2022-06-14 1:53 ` chenxiang (M)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3de4cf5-d760-1666-6b9c-f620c238453b@redhat.com \
--to=pbonzini@redhat.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mtosatti@redhat.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=sheng.yang@intel.com \
--cc=willy@infradead.org \
--cc=zhangfei.gao@foxmail.com \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.