Re: [PATCH v2 1/4] blk-iocost: charge flushes as pageless random writes

[Tao Cui <cui.tao@linux.dev>]

Hello Tejun,

在 2026/9/19 22:59, Tejun Heo 写道:
> Hello, Tao.
> 
> On Wed, Sep 16, 2026 at 04:53:01PM +0800, Tao Cui wrote:
>> Charge the flush component of any REQ_PREFLUSH bio on top of its data
>> cost, priced as a pageless random write (LCOEF_WRANDIO), which provides
>> an approximation of the device time consumed by a flush.  For profiles
>> where WRANDIO clamps to zero (ssd_dfl / ssd_fast), use a one-page floor
>> (LCOEF_WPAGE).
> 
> Pricing a flush as a random write, or as a page where that comes out to
> zero, is as arbitrary as pricing it at zero, and it changes what existing
> setups get charged. 013adcbef165 ("blk-iocost: skip empty flush bio in
> iocost") zeroed them because the flush machinery coalesces flushes and the
> write coefficients don't say anything about what a flush costs.
> 

Understood.  The write-coefficient pricing was only an approximation and
would change the accounting behavior for existing setups, so I'll drop it
and rework the series around a dedicated flush cost.

> Can you instead add the flushiops parameter you mentioned in the v1 thread
> to the linear model? A flush costs VTIME_PER_SEC / flushiops, and zero when
> the parameter isn't set, including in the builtin profiles, so nothing
> changes until it's configured or the profiles are regenerated with a flush
> measurement.
> 

Will do.  I'll add flushiops to the linear model using the same conversion
as the other iops coefficients:

- add a flushiops=%u token for io.cost.model and translate it to
  LCOEF_FLUSH = VTIME_PER_SEC / flushiops
- keep flushiops zero in builtin profiles, with no fallback, so existing
  profiles keep their current behavior
- account REQ_PREFLUSH and REQ_FUA consistently with the flush machinery:
  PREFLUSH charges one flush, and FUA adds another flush when the device
  does not support native FUA

The rest of the series (zone append charging, latency accounting, and the
comment fix) remains unchanged.

> The same charge should cover REQ_FUA the way the flush machinery does: one
> flush for PREFLUSH, and one for FUA on a device without FUA support, which
> is when a post-flush gets issued.
> 
> Please also drop the Fixes tag on this patch. With the parameter, this is
> an extension rather than a fix.
> 

Done.  v3 will position this as a cost model extension.

One remaining question is whether builtin profiles should eventually carry
measured flushiops values, or whether flushiops is expected to remain
user-configured.  This series leaves it at zero because I don't have
reliable measurements for the existing profiles.

Thanks,
Tao

> Thanks.
>