On Mon, May 04, 2026 at 06:38:54PM +0530, Arun George/Arun George wrote: > On 29-04-2026 07:12 pm, Gregory Price wrote: > > But I see this 'write budget' (budget in terms of number of write > operations that can be handled by the device, not capacity) to be > provided by the device in control plane; not by the workloads in the host. >
In the scenario i'm talking about, a "write budget" is defined as a number of pages that are allows to be mapped writable in the page tables at any given time. > 1) We can modulate the write budget depending on the actual > compressibility in the device (and so workloads data). We don't have to > do estimation based on the workloads. > Barring the device causing backpressure to increase latency and slow down writes, modulating a write budget doesn't actually do anything useful. Once a page is mapped writable - the CPU is free to write to that page uncontended. I think a write budget is "doable" but maybe a bit optimistic for an MVP. There are many corner cases to handle, and I would prefer to see that as an experimental optimization. > 2) We don't have to do the capacity modulation - as in ballooning or > shrinker. > You still need capacity modulation in some way to respond to drops in compression ratio. ~Gregory
