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 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.