From: "Richard W.M. Jones" <rjones@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Alex Kalenyuk <akalenyu@redhat.com>,
Adam Litke <alitke@redhat.com>,
qemu-devel@nongnu.org, kwolf@redhat.com, nsoffer@redhat.com
Subject: Re: qemu-img cache modes with Linux cgroup v1
Date: Mon, 31 Jul 2023 17:06:46 +0100 [thread overview]
Message-ID: <20230731160636.GO7636@redhat.com> (raw)
In-Reply-To: <20230731154036.GA1258836@fedora>
On Mon, Jul 31, 2023 at 11:40:36AM -0400, Stefan Hajnoczi wrote:
> 3. Using buffered I/O because O_DIRECT is not universally supported?
>
> If you can't use O_DIRECT, then qemu-img could be extended to manage its
> dirty page cache set carefully. This consists of picking a budget and
> writing back to disk when the budget is exhausted. Richard Jones has
> shared links covering posix_fadvise(2) and sync_file_range(2):
> https://lkml.iu.edu/hypermail/linux/kernel/1005.2/01845.html
> https://lkml.iu.edu/hypermail/linux/kernel/1005.2/01953.html
>
> We can discuss qemu-img code changes and performance analysis more if
> you decide to take that direction.
There's a bit more detail in these two commits:
https://gitlab.com/nbdkit/libnbd/-/commit/64d50d994dd7062d5cce21f26f0e8eba0e88c87e
https://gitlab.com/nbdkit/nbdkit/-/commit/a956e2e75d6c88eeefecd967505667c9f176e3af
In my experience this method is much better than using O_DIRECT,
it has much fewer sharp edges.
By the way, this is a super-useful tool for measuring how much of the
page cache is being used to cache a file:
https://github.com/Feh/nocache
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
next prev parent reply other threads:[~2023-07-31 16:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-31 15:40 qemu-img cache modes with Linux cgroup v1 Stefan Hajnoczi
2023-07-31 16:06 ` Richard W.M. Jones [this message]
2023-07-31 17:19 ` Daniel P. Berrangé
2023-07-31 19:15 ` Stefan Hajnoczi
2024-05-06 17:10 ` Alex Kalenyuk
2024-05-06 18:24 ` Stefan Hajnoczi
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=20230731160636.GO7636@redhat.com \
--to=rjones@redhat.com \
--cc=akalenyu@redhat.com \
--cc=alitke@redhat.com \
--cc=kwolf@redhat.com \
--cc=nsoffer@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).