On Thu, May 09, 2024 at 07:48:46PM +0200, David Hildenbrand wrote: > On 08.05.24 21:23, Luis Chamberlain wrote: > > From my perspective the more shared code the better, and the more shared > > paths the better. There is a chance to help test swap with large folios > > instead of splitting the folios for swap, and that would could be done > > first with tmpfs. I have not evaluated the difference in testing or how > > we could get the most of shared code if we take a mTHP approach or the > > iomap approach for tmpfs, that should be considered. > > I don't have a clear picture yet of what might be best for ordinary shmem > (IOW, not MAP_SHARED|MAP_PRIVATE), and I'm afraid there is no easy answer. OK so it sounds like the different options needs to be thought out and reviewed. > As long as we don't end up wasting memory, it's not obviously bad. Sure. > But some > things might be tricky (see my example about large folios stranding in shmem > and never being able to be really reclaimed+reused for better purposes) Where is that stated BTW? Could that be resolved? > I'll note that mTHP really is just (supposed to be) a user interface to > enable the various folio sizes (well, and to expose better per-size stats), > not more. Sure but given filesystems using large folios don't have silly APIs for using which large folios to enable, it just seems odd for tmpfs to take a different approach. > From that point of view, it's just a filter. Enable all, and you get the > same behavior as you likely would in the pagecache mode. Which begs the quesiton, *why* have an API to just constrain to certain large folios, which diverges from what filesystems are doing with large folios? > > Are there other things to consider? Does this require some dialog at > > LSFMM? > > As raised in my reply to Daniel, I'll be at LSF/MM and happy to discuss. I'm > also not a SHMEM expert, so I'm hoping at some point we'd get feedback from > Hugh. Hugh, will you be at LSFMM? Luis
