On Thu, Feb 22, 2024 at 5:32 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Thu, Feb 22, 2024 at 05:16:44PM -0500, Pasha Tatashin wrote: > > However, we must also ensure compatibility with the interfaces and > > features unique to hugetlb, such as boot-time reservation and vmemap > > optimizations. Generalizing these features could potentially lead to > > memory savings in THP as well. > > In a memdesc world, how much value is there in vmemmap? At 8 bytes per > page, memmap occupies 4kB for 2MB and 2MB for 1GB. So there's no way > to save memory for a 2MB allocation, and saving 2MB per 1GB page is > ... not a huge win any more. Let's say you have a 64GB machine with > 50GB tied up in 1GB pages, we'll end up saving 100MB on a 64GB machine > which doesn't seem all that compelling? I agree that memdesc may eliminate the need for vmemmap optimizations. However, do we want to introduce regressions before transitioning to a memdesc world? Companies are currently saving petabytes of memory with vmemmap optimizations. > I do have a proposal for further compressing memmap, but it requires > doing memdesc first, so I'm reluctant to discuss it before we've done > memdescs. I have to have something to talk about at LSFMM'26 after all.
