On Tue, Oct 29, 2019 at 07:08:42AM +0000, Christopher Lameter wrote: > On Mon, 28 Oct 2019, Kirill A. Shutemov wrote: > > > Setting a single 4k page non-present in the direct mapping will require > > splitting 2M or 1G page we usually map direct mapping with. And it's one > > way road. We don't have any mechanism to map the memory with huge page > > again after the application has freed the page. > > > > It might be okay if all these pages cluster together, but I don't think we > > have a way to achieve it easily. > > Set aside a special physical memory range for this and migrate the > page to that physical memory range when MAP_EXCLUSIVE is specified? I've talked with Thomas yesterday and he suggested something similar: When the MAP_EXCLUSIVE request comes for the first time, we allocate a huge page for it and then use this page as a pool of 4K pages for subsequent requests. Once this huge page is full we allocate a new one and append it to the pool. When all the 4K pages that comprise the huge page are freed the huge page is collapsed. And then on top of this we can look into compaction of the direct map. Of course, this would work if the easy way of collapsing direct map pages Kirill mentioned on other mail will work. > Maybe some processors also have hardware ranges that offer additional > protection for stuff like that? > -- Sincerely yours, Mike.
