Re: Some performance numbers for virtiofs, DAX and virtio-9p

[Miklos Szeredi]

On Fri, Dec 11, 2020 at 8:25 PM Vivek Goyal <vgoyal@redhat.com> wrote:
>
> 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.

Can we dynamically increase the dax window size?  Or hot plug
additional dax ranges on demand?

That would solve the problem of trying to find the active set size in advance.

We'd still need reclaim in order to prevent the window from growing
indefinitely, but that would always be background reclaim and be done
after some time of inactivity.

Thanks,
Miklos