On Wed, 29 Jan 2025 at 17:35, Brendan Jackman <jackmanb@xxxxxxxxxx> wrote: > > Although we’ve been able to hammer this approach into a viable shape for the > > Google workloads we’ve been concerned with so far, it’s not a general solution. > > Some concrete reasons include: > > > > a. It leads to pointless TLB shootdowns; there must be pathological cases where > > lots of pages get un-mapped only to get immediately re-allocated and mapped > > again. > > > > b. The asynchronous worker creates CPU jitter. > > > > v. It provides no ability to prioritise re-allocating pages with the same > > sensitivity as prior allocations. As well as TLB issues this creates page > > zeroing costs as pages that were formerly sensitive need to be zeroed before > > they can be mapped into the restricted address space. > > > > d. This all creates unnecessary allocation latency and extra work to free pages. Oh I forgot another important detail: this uses a pageflag to track whether a page is currently mapped in the restricted address space. That isn't necessary, a proper page_alloc integration should get rid of that. Anyway, while important it isn't the hard/interesting part. If we got really stuck on this point, we could probably always resort to walking the ASI pagetables to see if the page is mapped.
