Re: can we finally kill off CONFIG_FS_DAX_LIMITED

[Gerald Schaefer <gerald.schaefer@linux.ibm.com>]

On Fri, 20 Aug 2021 10:42:14 -0700
Dan Williams <dan.j.williams@intel.com> wrote:

> [ fix Gerald's email ]
> 
> On Fri, Aug 20, 2021 at 8:41 AM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > [ add Gerald and Joao ]
> >
> > On Thu, Aug 19, 2021 at 10:44 PM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > Hi all,
> > >
> > > looking at the recent ZONE_DEVICE related changes we still have a
> > > horrible maze of different code paths.  I already suggested to
> > > depend on ARCH_HAS_PTE_SPECIAL for ZONE_DEVICE there, which all modern
> > > architectures have anyway.  But the other odd special case is
> > > CONFIG_FS_DAX_LIMITED which is just used for the xpram driver.  Does
> > > this driver still see use?  If so can we make it behave like the
> > > other DAX drivers and require a pgmap?  I think the biggest missing
> > > part would be to implement ARCH_HAS_PTE_DEVMAP for s390.
> > >
> >
> > Gerald,
> >
> > Might you still be looking to help dcssblk get out of FS_DAX_LIMITED
> > jail [1]? I recall Martin saying that 'struct page' overhead was
> > prohibitive. I don't know if Joao's 'struct page' diet patches could
> > help alleviate that at all (would require the filesystem to only
> > allocate blocks in large page sizes).
> >
> > [1]: https://lore.kernel.org/r/20180523205017.0f2bc83e@thinkpad

Ouch, yes, that is actually (still) on my list. Also, adding struct
pages for dcssblk in XIP / DAX mode is not really prohibitive. The
whole feature was designed to allow saving memory when the same
binaries need to be executed from many z/VM guests. The XIP
(execute-in-place) part allows to execute them directly from the
DCSS (shared) memory segment, saving page cache usage on all guests.

Additionally saving the struct pages for the DCSS memory itself can
be considered a bonus, but it's just 1/64th of the otherwise saved
memory. For this reason, and also because there are hardly any users
of that feature left, we certainly can do w/o that, i.e. live with
having the struct pages.

I must admit that I neglected this a bit, and it was only a question
of time until this popped up again (rightfully). I understand that
having and maintaining this FS_DAX_LIMITED workaround is really ugly.

So I will give this some priority now, and I hope that it still only
affects dcssblk, and we did not get any other non-s390 users in the
meantime.

BTW, s390 xpram driver should not be affected. AFAIR, we also might
not have struct pages there, but it also is not possible to use it
with DAX, so it should not care about FS_DAX_LIMITED.