On Sun, Dec 31, 2023 at 02:35:23PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > Map the xfile pages directly into xfs_buf to reduce memory overhead. > It's silly to use memory to stage changes to shmem pages for ephemeral > btrees that don't care about transactionality. Looking at the users if seems like this is in fact the online use case - PAGE_SIZE sized btree blocks, which by nature of coming from shmem must be aligned. So I'd suggest we remove the non-mapped file path and just always use this one with sufficient sanity checks to trip over early if that assumption doesn't hold true. The users also alway just has a single map per buffer, and a single page per buffer so it really shouldn't support anything else. Writing it directly to shmemfs will probably simply things as well as it just needs to do a shmem_read_mapping_page_gfp to read the one page per buffer, and then a set_page_dirty on the locked page when releasing it. Talking about relasing it: this now gets us back to the old pagebuf problem of competing LRUs, one for the xfs_buf, and then anothr for the shmemfs page in the page cache. I suspect not putting the shmemfs backed buffers onto the LRU at all might be a good thing, but that requires careful benchmarking.
