qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	"Venegas Munoz,
	Jose Carlos" <jose.carlos.venegas.munoz@intel.com>,
	Christian Schoenebeck <qemu_oss@crudebyte.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	virtio-fs-list <virtio-fs@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: Some performance numbers for virtiofs, DAX and virtio-9p
Date: Fri, 11 Dec 2020 14:25:17 -0500	[thread overview]
Message-ID: <20201211192517.GF3285@redhat.com> (raw)
In-Reply-To: <20201211182956.GF3380@work-vm>

On Fri, Dec 11, 2020 at 06:29:56PM +0000, Dr. David Alan Gilbert wrote:

[..]
> > > 
> > > Could we measure at what point does a large window size actually make
> > > performance worse?
> > 
> > Will do. Will run tests with varying window sizes (small to large)
> > and see how does it impact performance for same workload with
> > same guest memory.
> 
> I wonder how realistic it is though;  it makes some sense if you have a
> scenario like a fairly small root filesystem - something tractable;  but
> if you have a large FS you're not realistically going to be able to set
> the cache size to match it - that's why it's a cache!

I think its more about active dataset size and not necessarily total
FS size. FS might be big but if application is not accessing all of
the in reasonabl small time window, then it does not matter.

What worries me most is that cost of reclaim of a dax range seems
too high (or keeps the process blocked for long enogh), that it
kills the performance. I will need to revisit the reclaim path
and see if I can optimize something.

Vivek



  reply	other threads:[~2020-12-11 19:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10 16:11 Some performance numbers for virtiofs, DAX and virtio-9p Vivek Goyal
2020-12-10 19:29 ` Miklos Szeredi
2020-12-11 16:06   ` Vivek Goyal
2020-12-11 18:29     ` Dr. David Alan Gilbert
2020-12-11 19:25       ` Vivek Goyal [this message]
2020-12-11 20:01         ` Vivek Goyal
2020-12-11 20:06           ` Dr. David Alan Gilbert
2021-01-05 15:08         ` Miklos Szeredi
2021-01-05 15:45           ` Vivek Goyal
2020-12-11 18:47     ` Vivek Goyal

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=20201211192517.GF3285@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=jose.carlos.venegas.munoz@intel.com \
    --cc=mszeredi@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-fs@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 NNTP newsgroup(s).