3 ms·

Hi, Mesh co-author here. Mesh should not introduce any additional TLB pressure - the number of virtual pages remains the same, so the number of TLB entries does

Hi, Mesh co-author here. Mesh should not introduce any additional TLB pressure - the number of virtual pages remains the same, so the number of TLB entries does not change. It remaps existing virtual pages to the same physical page once they have been meshed. Using huge pages is an entirely different question, and one that would require novel techniques to adapt meshing to that setting.

anonymoushn 3y ago
If for example you have some pages that are used for 64b objects, and you merge them to be backed by the same physical page, and then the user allocates more 64b objects such that a 2nd physical page of 64b objects must be allocated, they're now using 3 virtual pages for their 2 physical pages worth of 64b objects. With an allocator that does not point multiple virtual pages at the same physical page, they could only be using 2 virtual pages for their 64b objects. So more TLB entries are not required immediately when pages are merged, they are required later when more objects are allocated. It's certainly possible that I've misunderstood and the pages are actually un-merged by Mesh at this point so that new allocations can be served from the existing 2 half-full virtual pages (which are now backed by 2 separate half-full physical pages).
- emeryberger 3y ago
  In the steady state, I would not expect this to happen. Mesh prefers to allocate from nearly full virtual pages (see Section 3.1). This gives emptier pages time to get emptier; once they become completely empty, their virtual addresses can be reclaimed. In short, Mesh maintains roughly the same TLB footprint (note: we should otherwise have observed a performance decrease, which we did not), while significantly reducing physical memory consumption. It's also worth noting that meshing is only triggered when memory is fragmented and the heap is sparsely occupied, so it really lowers the peaks of physical memory consumption exactly at the moment when meshing helps the most, and at the same time, has no impact on the TLB (except of course updating entries).

anonymoushn 3y ago

If for example you have some pages that are used for 64b objects, and you merge them to be backed by the same physical page, and then the user allocates more 64b objects such that a 2nd physical page of 64b objects must be allocated, they're now using 3 virtual pages for their 2 physical pages worth of 64b objects. With an allocator that does not point multiple virtual pages at the same physical page, they could only be using 2 virtual pages for their 64b objects. So more TLB entries are not required immediately when pages are merged, they are required later when more objects are allocated. It's certainly possible that I've misunderstood and the pages are actually un-merged by Mesh at this point so that new allocations can be served from the existing 2 half-full virtual pages (which are now backed by 2 separate half-full physical pages).

emeryberger 3y ago
In the steady state, I would not expect this to happen. Mesh prefers to allocate from nearly full virtual pages (see Section 3.1). This gives emptier pages time to get emptier; once they become completely empty, their virtual addresses can be reclaimed. In short, Mesh maintains roughly the same TLB footprint (note: we should otherwise have observed a performance decrease, which we did not), while significantly reducing physical memory consumption. It's also worth noting that meshing is only triggered when memory is fragmented and the heap is sparsely occupied, so it really lowers the peaks of physical memory consumption exactly at the moment when meshing helps the most, and at the same time, has no impact on the TLB (except of course updating entries).