On Fri, 2026-01-16 at 17:28 +0000, Nikita Kalyazin wrote: > > > > I imagine this feature is really targeted towards machines running > > a bunch of untrusted VMs, so cloud hypervisors really. In that case > > the direct map will probably be carved up pretty quick. Did you > > consider just breaking the full direct map to 4k at the start when > > it's in use? > > That's an interesting point, I haven't thought about it from this > perspective. We should run some tests internally to see if it'd > help. This will likely change with support for huge pages coming in > though.
The thing is, those no_flush() helpers actually still flush if they need to split a page. Plus if they need to clear out lazy vmalloc aliases it could be another flush. There are probably a lot of opportunities to reduce flushing even beyond pre-split. Just curious... as far as performance, have you tested this on a big multi-socket system, where that flushing will hurt more? It's something that has always been a fear for these directmap unmapping solutions
