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