mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tao Cui <cui.tao@linux.dev>
To: Tejun Heo <tj@kernel.org>
Cc: cui.tao@linux.dev, Josef Bacik <josef@toxicpanda.com>,
	josef@toxicopanda.com, Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@infradead.org>,
	cgroups@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, cuitao@kylinos.cn
Subject: Re: [PATCH v2 2/4] blk-iocost: charge zone appends as page-counted sequential writes
Date: Sun, 20 Sep 2026 15:13:12 +0800	[thread overview]
Message-ID: <7674b311-52a9-4a88-80c9-65a37383b4ab@linux.dev> (raw)
In-Reply-To: <084ec3b97432a6d1520948417d9b9bc1@kernel.org>

Hello Tejun,

在 2026/9/19 23:00, Tejun Heo 写道:
> Hello, Tao.
> 
> On Wed, Sep 16, 2026 at 04:53:02PM +0800, Tao Cui wrote:
>> A zone append advances the zone write pointer and is therefore
>> sequential from the device's perspective; the actual sector is only
>> returned after completion, so the cursor-based seq/rand classification
>> doesn't apply.  Price it as a page-counted sequential write.
> 
> Whether an append is cheap depends on where the previous IO went, the same
> as for a regular write, and the cursor already tracks that. The sector is
> the zone start rather than the write pointer, but the cursor gets set from
> the same sector, so back-to-back appends to the same zone are a bio length
> apart and classify sequential, appends to different zones are a zone apart
> and classify random, and emulated appends already arrive here as regular
> writes at the write pointer.
> 
> It isn't exact. A read or regular write into a zone being appended to is
> measured from the zone start rather than the write pointer, so it drifts
> toward random as the zone fills, and the last append in one zone and the
> first in the next are contiguous but compute as a zone apart. Both are
> bounded by the difference between the seq and rand base costs of one IO,
> which is small on the flash devices that do native appends. Mostly right
> is fine here. Can you just add REQ_OP_ZONE_APPEND to the REQ_OP_WRITE case
> and leave the cursor update alone?
> 

That fits the existing model better than the special handling I
introduced.  I had missed that the cursor is set from the same
zone-start sector on every append, so back-to-back appends classify
sequential as expected, and that emulated appends already take the regular
WRITE path.

I'll drop the special case and the cursor skip in v3 and just add
REQ_OP_ZONE_APPEND to the REQ_OP_WRITE case.

> Also, the Fixes tags on this patch and 3/4 should point at 0512a75b98f8
> ("block: Introduce REQ_OP_ZONE_APPEND"), which added the op without pricing
> it, rather than the iocost commit that predates it.
> 

Agreed, that's the right anchor - the gap appeared when the op was
added.  Both Fixes tags will be updated.

Thanks.

> Thanks.
> 


  reply	other threads:[~2026-09-20  7:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  8:53 [PATCH v2 0/4] blk-iocost: charge flushes and zone appends Tao Cui
2026-09-16  8:53 ` [PATCH v2 1/4] blk-iocost: charge flushes as pageless random writes Tao Cui
2026-09-18 13:21   ` Christoph Hellwig
2026-09-19 14:59   ` Tejun Heo
2026-09-20  7:08     ` Tao Cui
2026-09-16  8:53 ` [PATCH v2 2/4] blk-iocost: charge zone appends as page-counted sequential writes Tao Cui
2026-09-18 13:22   ` Christoph Hellwig
2026-09-20  7:11     ` Tao Cui
2026-09-19 15:00   ` Tejun Heo
2026-09-20  7:13     ` Tao Cui [this message]
2026-09-16  8:53 ` [PATCH v2 3/4] blk-iocost: account zone append completions in latency stats Tao Cui
2026-09-18 13:22   ` Christoph Hellwig
2026-09-16  8:53 ` [PATCH v2 4/4] blk-iocost: fix stale comment in ioc_rqos_throttle() Tao Cui
2026-09-18 13:23   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7674b311-52a9-4a88-80c9-65a37383b4ab@linux.dev \
    --to=cui.tao@linux.dev \
    --cc=axboe@kernel.dk \
    --cc=cgroups@vger.kernel.org \
    --cc=cuitao@kylinos.cn \
    --cc=hch@infradead.org \
    --cc=josef@toxicopanda.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®