From: Nadav Amit <namit@vmware.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ajay Kaher <akaher@vmware.com>,
Bjorn Helgaas <helgaas@kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
Srivatsa Bhat <srivatsab@vmware.com>,
"srivatsa@csail.mit.edu" <srivatsa@csail.mit.edu>,
Alexey Makhalov <amakhalov@vmware.com>,
Anish Swaminathan <anishs@vmware.com>,
Vasavi Sirnapalli <vsirnapalli@vmware.com>,
"er.ajay.kaher@gmail.com" <er.ajay.kaher@gmail.com>
Subject: Re: [PATCH] MMIO should have more priority then IO
Date: Fri, 8 Jul 2022 16:45:00 +0000 [thread overview]
Message-ID: <96D533E5-F3AF-4062-B095-8C143C307E37@vmware.com> (raw)
In-Reply-To: <YsgplrrJnk5Ly19z@casper.infradead.org>
On Jul 8, 2022, at 5:56 AM, Matthew Wilcox <willy@infradead.org> wrote:
> And looking at the results above, it's not so much the PIO vs MMIO
> that makes a difference, it's the virtualisation. A mmio access goes
> from 269ns to 85us. Rather than messing around with preferring MMIO
> over PIO for config space, having an "enlightenment" to do config
> space accesses would be a more profitable path.
I am unfamiliar with the motivation for this patch, but I just wanted to
briefly regard the advice about enlightments.
“enlightenment”, AFAIK, is Microsoft’s term for "para-virtualization", so
let’s regard the generic term. I think that you consider the bare-metal
results as the possible results from a paravirtual machine, which is mostly
wrong. Para-virtualization usually still requires a VM-exit and for the most
part the hypervisor/host runs similar code for MMIO/hypercall (conceptually;
the code of paravirtual and fully-virtual devices is often different, but
IIUC, this is not what Ajay measured).
Para-virtualization could have *perhaps* helped to reduce the number of
PIO/MMIO and improve performance this way. If, for instance, all the
PIO/MMIO are done during initialization, a paravirtual interface can be use
to batch them together, and that would help. But it is more complicated to
get a performance benefit from paravirtualization if the PIO/MMIO accesses
are “spread”, for instance, done after each interrupt.
Para-virtauilzation and full-virtualization both have pros and cons.
Para-virtualization is many times more efficient, but requires the VM to
have dedicated device drivers for the matter. Try to run a less-common OS
than Linux and it would not work since the OS would not have drivers for the
paras-virtual devices. And even if you add support today for a para-virtual
devices, there are many deployed OSes that do not have such support, and you
would not be able to run them in a VM.
Regardless to virtualization, Ajay’s results show PIO is slower on
bare-metal, and according to his numbers by 165ns, which is significant.
Emulating PIO in hypervisors on x86 is inherently more complex than MMIO, so
the results he got would most likely happen on all hypervisors.
tl;dr: Let’s keep this discussion focused and put paravirtualization aside.
It is not a solution for all the problems in the world.
next prev parent reply other threads:[~2022-07-08 16:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 16:29 Ajay Kaher
2022-06-28 18:09 ` Bjorn Helgaas
2022-07-08 5:56 ` Ajay Kaher
2022-07-08 12:56 ` Matthew Wilcox
2022-07-08 16:45 ` Nadav Amit [this message]
2022-07-08 17:55 ` Matthew Wilcox
2022-07-08 18:35 ` Nadav Amit
2022-07-08 18:43 ` Matthew Wilcox
2022-07-08 19:49 ` Nadav Amit
2022-07-11 6:31 ` Ajay Kaher
2022-07-11 17:04 ` Nadav Amit
2022-07-11 17:53 ` Ajay Kaher
2022-07-11 18:18 ` H. Peter Anvin
2022-07-11 19:43 ` Paolo Bonzini
2022-07-12 21:20 ` Shuah Khan
2022-08-31 21:44 ` Matthew Wilcox
2022-08-31 22:23 ` Shuah Khan
2022-06-29 6:12 ` Greg KH
2022-06-29 6:37 ` H. Peter Anvin
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=96D533E5-F3AF-4062-B095-8C143C307E37@vmware.com \
--to=namit@vmware.com \
--cc=akaher@vmware.com \
--cc=amakhalov@vmware.com \
--cc=anishs@vmware.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=er.ajay.kaher@gmail.com \
--cc=helgaas@kernel.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srivatsa@csail.mit.edu \
--cc=srivatsab@vmware.com \
--cc=tglx@linutronix.de \
--cc=vsirnapalli@vmware.com \
--cc=willy@infradead.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®