You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it stands, Mesh can't make effective use of huge pages -- its design depends on smallish pages (e.g., 4K).
Desired Behavior
Mesh would be able to take advantage of huge pages and the consequent reduction of TLB footprint (and thus likely increased performance for very large heaps).
Proposed Design
I think it'd be possible to make a huge-page version of Mesh that uses huge pages by treating some smaller grain chunk (e.g., 1/256th of the huge page size) as a single "bit" -- 1 if there is any memory allocated in that chunk, 0 otherwise. The smaller grain chunks could be managed by a more conventional allocator (possibly from a single size class). Then, meshing would operate on the bitmaps for the huge pages, essentially as it already does today for standard page sizes.
The text was updated successfully, but these errors were encountered:
I think this makes sense and feels like a nice, layered design. 1 thing to note @emeryberger is that we probably need to also adopt the current MiniHeaps for not-quite-huge-but-bigger pages, like the 16 KB page size on macOS. MiniHeaps have a 256-bit bitmap embedded in them in order to perfectly squeeze into a 64-byte cacheline. And then because the bitmap Is 256-bits, I believe there is at least 1 fields that expects to only be 1-byte in size (max objects) shoved into the Flags in the header. since we need 128-bytes for the 16k bits in the bitmap, it probably would make sense to expand the header from 32 to 64 bits and make MiniHeaps (in this case) 192 bytes (for reference M1's cache line size is 128 bytes). It seems tricky but possible to make this "just" a compile time detail with compile time magic
Issue
As it stands, Mesh can't make effective use of huge pages -- its design depends on smallish pages (e.g., 4K).
Desired Behavior
Mesh would be able to take advantage of huge pages and the consequent reduction of TLB footprint (and thus likely increased performance for very large heaps).
Proposed Design
I think it'd be possible to make a huge-page version of Mesh that uses huge pages by treating some smaller grain chunk (e.g., 1/256th of the huge page size) as a single "bit" -- 1 if there is any memory allocated in that chunk, 0 otherwise. The smaller grain chunks could be managed by a more conventional allocator (possibly from a single size class). Then, meshing would operate on the bitmaps for the huge pages, essentially as it already does today for standard page sizes.
The text was updated successfully, but these errors were encountered: