On Fri, 20 Aug 2021 10:42:14 -0700 Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > [ fix Gerald's email ] > > On Fri, Aug 20, 2021 at 8:41 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > > [ add Gerald and Joao ] > > > > On Thu, Aug 19, 2021 at 10:44 PM Christoph Hellwig <hch@xxxxxx> 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.
