From: Marc Zyngier <maz@kernel.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Shivam Kumar <shivam.kumar1@nutanix.com>,
pbonzini@redhat.com, james.morse@arm.com,
borntraeger@linux.ibm.com, david@redhat.com, kvm@vger.kernel.org,
Shaju Abraham <shaju.abraham@nutanix.com>,
Manish Mishra <manish.mishra@nutanix.com>,
Anurag Madnawat <anurag.madnawat@nutanix.com>
Subject: Re: [PATCH v4 1/4] KVM: Implement dirty quota-based throttling of vcpus
Date: Thu, 26 May 2022 17:16:08 +0100 [thread overview]
Message-ID: <877d68mfqv.wl-maz@kernel.org> (raw)
In-Reply-To: <Yo+gTbo5uqqAMjjX@google.com>
On Thu, 26 May 2022 16:44:13 +0100,
Sean Christopherson <seanjc@google.com> wrote:
>
> On Thu, May 26, 2022, Marc Zyngier wrote:
> > > >> +{
> > > >> + struct kvm_run *run = vcpu->run;
> > > >> + u64 dirty_quota = READ_ONCE(run->dirty_quota);
> > > >> + u64 pages_dirtied = vcpu->stat.generic.pages_dirtied;
> > > >> +
> > > >> + if (!dirty_quota || (pages_dirtied < dirty_quota))
> > > >> + return 1;
> > > > What happens when page_dirtied becomes large and dirty_quota has to
> > > > wrap to allow further progress?
> > > Every time the quota is exhausted, userspace is expected to set it to
> > > pages_dirtied + new quota. So, pages_dirtied will always follow dirty
> > > quota. I'll be sending the qemu patches soon. Thanks.
> >
> > Right, so let's assume that page_dirtied=0xffffffffffffffff (yes, I
> > have dirtied that many pages).
>
> Really? Written that many bytes from a guest? Maybe. But actually
> marked that many pages dirty in hardware, let alone in KVM? And on
> a single CPU?
>
> By my back of the napkin math, a 4096 CPU system running at 16ghz
> with each CPU able to access one page of memory per cycle would take
> ~3 days to access 2^64 pages.
>
> Assuming a ridiculously optimistic ~20 cycles to walk page tables,
> fetch the cache line from memory, insert into the TLB, and mark the
> PTE dirty, that's still ~60 days to actually dirty that many pages
> in hardware.
>
> Let's again be comically optimistic and assume KVM can somehow
> propagate a dirty bit from hardware PTEs to the dirty bitmap/ring in
> another ~20 cycles. That brings us to ~1200 days.
>
> But the stat is per vCPU, so that actually means it would take
> ~13.8k years for a single vCPU/CPU to dirty 2^64 pages... running at
> a ludicrous 16ghz on a CPU with latencies that are a likely an order
> of magnitude faster than anything that exists today.
Congratulations, you can multiply! ;-)
It just shows that the proposed API is pretty bad, because instead of
working as a credit, it works as a ceiling, based on a value that is
dependent on the vpcu previous state (forcing userspace to recompute
the next quota on each exit), and with undocumented, arbitrary limits
as a bonus.
I don't like it, and probably won't like it in 13.8k years either.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-05-26 16:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-21 20:29 [PATCH v4 0/4] KVM: Dirty quota-based throttling Shivam Kumar
2022-05-21 20:29 ` [PATCH v4 1/4] KVM: Implement dirty quota-based throttling of vcpus Shivam Kumar
2022-05-24 7:11 ` Marc Zyngier
2022-05-26 9:33 ` Shivam Kumar
2022-05-26 13:30 ` Marc Zyngier
2022-05-26 15:44 ` Sean Christopherson
2022-05-26 16:16 ` Marc Zyngier [this message]
2022-05-26 17:46 ` Sean Christopherson
2022-05-30 11:05 ` Shivam Kumar
2022-07-05 7:21 ` Shivam Kumar
2022-07-14 18:04 ` Peter Xu
2022-07-14 20:48 ` Sean Christopherson
2022-07-14 22:19 ` Peter Xu
2022-07-15 16:23 ` Sean Christopherson
2022-07-15 16:56 ` Peter Xu
2022-07-15 17:07 ` Sean Christopherson
2022-07-15 17:26 ` Peter Xu
2022-07-15 22:38 ` Sean Christopherson
2022-05-21 20:29 ` [PATCH v4 2/4] KVM: arm64: Dirty " Shivam Kumar
2022-05-24 7:14 ` Marc Zyngier
2022-05-26 9:16 ` Shivam Kumar
2022-05-26 17:58 ` Sean Christopherson
2022-05-21 20:29 ` [PATCH v4 3/4] KVM: s390x: " Shivam Kumar
2022-05-21 20:29 ` [PATCH v4 4/4] KVM: selftests: Add selftests for dirty quota throttling Shivam Kumar
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=877d68mfqv.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anurag.madnawat@nutanix.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=manish.mishra@nutanix.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=shaju.abraham@nutanix.com \
--cc=shivam.kumar1@nutanix.com \
/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.