From: Vivek Goyal <vgoyal@redhat.com>
To: JeffleXu <jefflexu@linux.alibaba.com>
Cc: virtio-fs@redhat.com, joseph.qi@linux.alibaba.com, miklos@szeredi.hu
Subject: Re: [Virtio-fs] [virtiofsd PATCH v6 5/6] virtiofsd: implement file size based dax policy
Date: Mon, 1 Nov 2021 09:18:54 -0400 [thread overview]
Message-ID: <YX/pPpb3OwCVdIx1@redhat.com> (raw)
In-Reply-To: <526d3ccc-72ab-ddfe-404b-33667a19583e@linux.alibaba.com>
On Mon, Nov 01, 2021 at 04:59:20PM +0800, JeffleXu wrote:
>
>
> On 10/21/21 1:54 AM, Vivek Goyal wrote:
> > On Mon, Oct 11, 2021 at 11:09:37AM +0800, Jeffle Xu wrote:
> >> When DAX window is fully utilized and needs to be expanded to avoid the
> >> performance fluctuation triggered by DAX window recaliming, it may not
> >> be wise to allocate DAX window for files with size smaller than some
> >> specific point, considering from the perspective of reducing memory
> >> overhead.
> >>
> >> To maintain one DAX window chunk (e.g., 2MB in size), 32KB
> >> (512 * 64 bytes) memory footprint will be consumed for page descriptors
> >> inside guest. Thus it'd better disable DAX for those files smaller than
> >> 32KB, to reduce the demand for DAX window and thus avoid the unworthy
> >> memory overhead.
> >>
> >> Thus only flag the file with FUSE_ATTR_DAX when the file size is greater
> >> than 32 KB. The guest will enable DAX only for those files flagged with
> >> FUSE_ATTR_DAX, when virtiofs is mounted with '-o dax=inode'.
> >>
> >> To be noted that both FUSE_LOOKUP and FUSE_READDIRPLUS are affected, and
> >> will convey FUSE_ATTR_DAX flag to the guest.
> >>
> >> This policy will be used when '-o dax=server' option is specified for
> >> virtiofsd.
> >
> > So enabling DAX based on size is just one type of policy. Tomorrow one
> > could think of enabling DAX on some other attribute. So only enable it
> > for non-executable files etc.
> >
> > We could be more specific and define a policy say "-o dax=filesize". This
> > will allow defining other policies easily later.
> >
> > But problem with this option is that defining more complex policies
> > will be hard. Say I want to enable DAX on non-executable files which
> > have size greater than 32K. Being able to combine multiple policies
> > will be easy if we implement separate options/knobs to control them
> > and that will allow turning on multiple policies together.
> >
> > Say, -o dax_size_threshold=1MB -o dax_no_exec_file
> >
> > So I guess a generic "-o dax=server" is not a bad idea. As of now this
> > will implement a default size based policy of 32K size. But one can add
> > options later to tweak this.
> >
>
> The reason why I originally use the 'dax=server' name is that, I want to
> emphasize that it's a heuristic strategy implemented by virtiofsd
> itself. But now I realized that the input of virtiofsd is all various
> kinds of file attributes, e.g. filesize, persistent inode flags, file
> type, etc, and so "dax=attr" name is also a vague name in this degree.
>
> Now I prefer "dax=filesize" and "dax=xflag", which shall be more clear
> to users at the first glance. The former allows DAX for those smaller
> than 32KB, while the latter queries the persistent DAX inode flag and
> allows DAX accordingly.
>
> w.r.t. the complex policy you described, e.g. 'non-executable files
> which have size greater than 32K', indeed we may need more option knobs
> then, maybe "dax=filesize|xflag" need to be transformed to
> "dax_filesize" and "dax_xflag"? But one problem of this multiple option
> knob design is that, it may be meaningless to specify "dax_filesize" and
> "dax_xflag" at the same time.
>
> In a summary, personally I prefer "dax=filesize" and "dax=xflag" so far,
> and we can tweak this, e.g. expand to multiple option knobs, if it's
> really needed later.
Agreed that more complex policy knobs can come later. Say one wants
to enable dax on every file except file smaller than 32K and on executable
files. Then we could probaby extend syntax to "dax=filesize,no_exec".
I like "dax=filesize". Little concerned about "dax=xflag" as xflag is
pretty generic for all kind of flags. How about "dax=inode" instead. This
is also generic, but atleast matches kernel mount option. Alternatively,
how about "dax=xflag_dax".
May be "dax=inode" will be more intuitive as kernel already has defined
semantics for this.
Thanks
Vivek
next prev parent reply other threads:[~2021-11-01 13:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 3:09 [Virtio-fs] [virtiofsd PATCH v6 0/6] virtiofsd: support per-file DAX Jeffle Xu
2021-10-11 3:09 ` [Virtio-fs] [virtiofsd PATCH v6 1/6] virtiofsd: add .ioctl() support Jeffle Xu
2021-10-15 2:49 ` [Virtio-fs] [virtiofsd PATCH v7 " Jeffle Xu
2021-10-20 17:36 ` [Virtio-fs] [virtiofsd PATCH v6 " Vivek Goyal
2021-10-21 2:32 ` JeffleXu
2021-10-11 3:09 ` [Virtio-fs] [virtiofsd PATCH v6 2/6] virtiofsd: support per-file DAX in fuse protocol Jeffle Xu
2021-10-11 3:09 ` [Virtio-fs] [virtiofsd PATCH v6 3/6] virtiofsd: negotiate per-file DAX in FUSE_INIT Jeffle Xu
2021-10-11 3:09 ` [Virtio-fs] [virtiofsd PATCH v6 4/6] virtiofsd: add 'dax=' option Jeffle Xu
2021-10-11 3:09 ` [Virtio-fs] [virtiofsd PATCH v6 5/6] virtiofsd: implement file size based dax policy Jeffle Xu
2021-10-20 17:54 ` Vivek Goyal
2021-11-01 8:59 ` JeffleXu
2021-11-01 13:18 ` Vivek Goyal [this message]
2021-10-11 3:09 ` [Virtio-fs] [virtiofsd PATCH v6 6/6] virtiofsd: implement persistent inode attribute " Jeffle Xu
2021-10-20 17:55 ` 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=YX/pPpb3OwCVdIx1@redhat.com \
--to=vgoyal@redhat.com \
--cc=jefflexu@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=miklos@szeredi.hu \
--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 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.