On 05/07/2024 06:47, Baolin Wang wrote: > > > On 2024/7/5 03:49, Matthew Wilcox wrote: >> On Thu, Jul 04, 2024 at 09:19:10PM +0200, David Hildenbrand wrote: >>> On 04.07.24 21:03, David Hildenbrand wrote: >>>>> shmem has two uses: >>>>> >>>>> - MAP_ANONYMOUS | MAP_SHARED (this patch set) >>>>> - tmpfs >>>>> >>>>> For the second use case we don't want controls *at all*, we want the >>>>> same heiristics used for all other filesystems to apply to tmpfs. >>>> >>>> As discussed in the MM meeting, Hugh had a different opinion on that. >>> >>> FWIW, I just recalled that I wrote a quick summary: >>> >>> https://lkml.kernel.org/r/f1783ff0-65bd-4b2b-8952-52b6822a0835@xxxxxxxxxx >>> >>> I believe the meetings are recorded as well, but never looked at recordings. >> >> That's not what I understood Hugh to mean. To me, it seemed that Hugh >> was expressing an opinion on using shmem as shmem, not as using it as >> tmpfs. >> >> If I misunderstood Hugh, well, I still disagree. We should not have >> separate controls for this. tmpfs is just not that special. I wasn't at the meeting that's being referred to, but I thought we previously agreed that tmpfs *is* special because in some configurations its not backed by swap so is locked in ram? > > But now we already have a PMD-mapped THP control for tmpfs, and mTHP simply > extends this control to per-size. > > IIUC, as David mentioned before, for tmpfs, mTHP should act like a huge order > filter which should be respected by the expected huge orders in the write() and > fallocate() paths. This would also solve the issue of allocating huge orders in > writable mmap() path for tmpfs, as well as unifying the interface. > > Anyway, I will try to provide an RFC to discuss the mTHP for tmpfs approach.
