Re: can we finally kill off CONFIG_FS_DAX_LIMITED

[Joao Martins <joao.m.martins@oracle.com>]

On 8/20/21 6:42 PM, Dan Williams wrote:
> 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).

/me nods

Either that or dynamically remapping the deduplicated tail page vmemmap
areas when we punch holes in what was represented as a compound page (or
when we collapse pages back together). Not sure how crazy the latter is.

>>
>> [1]: https://lore.kernel.org/r/20180523205017.0f2bc83e@thinkpad
>