From: "Michael S. Tsirkin" <mst@redhat.com>
To: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
virtualization@lists.linux-foundation.org
Subject: [virtio-dev] Re: presentation at kvm forum and pagefaults
Date: Fri, 1 Nov 2019 00:06:56 -0400 [thread overview]
Message-ID: <20191031234601-mutt-send-email-mst@kernel.org> (raw)
Regarding the presentation I gave at the kvm forum
on pagefaults.
Two points:
1. pagefaults are important not just for migration.
They are important for performance features such as
autonuma and huge pages, since this relies on moving
pages around.
Migration can maybe be solved by switch to software but
this is not a good solution for numa and thp since
at a given time some page is likely being moved.
2. For devices such as networking RX order in which buffers are
used *does not matter*.
Thus if a device gets a fault in response to attempt to store a buffer
into memory, it can just re-try, using the next buffer in queue instead.
This works because normally buffers can be used out of order by device.
The faulted buffer will be reused by another buffer when driver notifies
device page has been faulted in.
Note buffers are processed by buffer in the order in which they have
been used, *not* the order in which they have been put in the queue. So
this will *not* cause any packet reordering for the driver.
Packets will only get dropped if all buffers are swapped
out, which should be rare with a large RX queue.
As I said at the forum, a side buffer for X packets
to be stored temporarily is also additionally possible. But with the above
it is no longer strictly required.
This conflicts with the IN_ORDER feature flag, I guess we will have to
re-think this flag then. If we do feel we need to salvage IN_ORDER as is,
maybe device can use the buffer with length 0 and driver will re-post it
later, but I am not I am not sure about this since involving the VF
driver seems inelegant.
--
MST
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next reply other threads:[~2019-11-01 4:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-01 4:06 Michael S. Tsirkin [this message]
2019-11-01 8:51 ` [virtio-dev] Re: presentation at kvm forum and pagefaults Michael S. Tsirkin
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=20191031234601-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.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