On Thu, 11 Jan 2024 18:22:50 -0800 "Darrick J. Wong" <djwong@xxxxxxxxxx> wrote: > On Thu, Jan 11, 2024 at 10:45:53PM +0000, Matthew Wilcox wrote: > > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote: > > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong" <djwong@xxxxxxxxxx> wrote: > > > > > > > > > Fixing this will require a bit of an API change, and prefeably sorting out > > > > > > the hwpoison story for pages vs folio and where it is placed in the shmem > > > > > > API. For now use this one liner to disable large folios. > > > > > > > > > > > > Reported-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > > > > > > > > > > Can someone who knows more about shmem.c than I do please review > > > > > https://lore.kernel.org/linux-xfs/20240103084126.513354-4-hch@xxxxxx/ > > > > > so that I can feel slightly more confident as hch and I sort through the > > > > > xfile.c issues? > > > > > > > > > > For this patch, > > > > > Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > > > ...except that I'm still getting 2M THPs even with this enabled, so I > > > > guess either we get to fix it now, or create our own private tmpfs mount > > > > so that we can pass in huge=never, similar to what i915 does. :( > > > > > > What is "this"? Are you saying that $Subject doesn't work, or that the > > > above-linked please-review patch doesn't work? > > > > shmem pays no attention to the mapping_large_folio_support() flag, > > so the proposed fix doesn't work. It ought to, but it has its own way > > of doing it that predates mapping_large_folio_support existing. > > Yep. It turned out to be easier to fix xfile.c to deal with large > folios than I thought it would be. Or so I think. We'll see what > happens on fstestscloud overnight. Where do we stand with this? Should I merge these two patches into 6.8-rcX, cc:stable?
