On Mon, Jan 30, 2023, Oliver Upton wrote: > I think that Marc's suggestion of having userspace configure this is > sound. After all, userspace _should_ know the granularity of the backing > source it chose for guest memory. > > We could also interpret a cache size of 0 to signal that userspace wants > to disable eager page split for a VM altogether. It is entirely possible that > the user will want a differing QoS between slice-of-hardware and > overcommitted VMs. Maybe. It's also entirely possible that QoS is never factored in, e.g. if QoS guarantees for all VMs on a system are better met by enabling eager splitting across the board. There are other reasons to use module/kernel params beyond what Marc listed, e.g. to let the user opt out even when something is on by default. x86's TDP MMU has benefited greatly from downstream users being able to do A/B performance testing this way. I suspect x86's eager_page_split knob was added largely for this reason, e.g. to easily see how a specific workload is affected by eager splitting. That seems like a reasonable fit on the ARM side as well. IMO, we should try to avoid new uAPI without a proven need, especially if we're considering throwing something into memslots. AFAIK, module params, at least on the x86 side of things, aren't considered immutable ABI (or maybe it's just that we haven't modified/removed one recently that folks care about).
