On Sun, Dec 03, 2023 at 09:27:57PM +0000, Matthew Wilcox wrote: > I was talking with Darrick on Friday and he convinced me that this is > something we're going to need to fix sooner rather than later for the > benefit of devices with block size 8kB. So it's definitely on my todo > list, but I haven't investigated in any detail yet. OK, here's my initial analysis of just not putting order-1 folios on the deferred split list. folio->_deferred_list is only used in mm/huge_memory.c, which makes this a nice simple analysis. - folio_prep_large_rmappable() initialises the list_head. No problem, just don't do that for order-1 folios. - split_huge_page_to_list() will remove the folio from the split queue. No problem, just don't do that. - folio_undo_large_rmappable() removes it from the list if it's on the list. Again, no problem, don't do that for order-1 folios. - deferred_split_scan() walks the list, it won't find any order-1 folios. - deferred_split_folio() will add the folio to the list. Returning here will avoid adding the folio to the list. But what consequences will that have? Ah. There's only one caller of deferred_split_folio() and it's in page_remove_rmap() ... and it's only called for anon folios anyway. So it looks like we can support order-1 folios in the page cache without any change in behaviour since file-backed folios were never added to the deferred split list. Now, is this the right direction? Is it a bug that we never called deferred_split_folio() for pagecache folios? I would defer to Hugh or Kirill on this. Ccs added.
