Re: [PATCH 0/8] Improve zoned (SMR) HDD write throughput

[Damien Le Moal <dlemoal@kernel.org>]

On 2/24/26 2:03 AM, Bart Van Assche wrote:
> On 2/20/26 4:44 PM, Damien Le Moal wrote:
>> This patch series cleans up the zone write plugging code and introduces
>> the ability to issue all write BIOs from a single context (a kthread)
>> instead of allowing multiple zones to be written at the same time using
>> a per zone work. As shown in patch 6, raw block device tests and XFS
>> tests with an SMR HDD show that this can significantly increase write
>> throughput (up to 40% over the current zone write plugging).
> Hi Damien,
> 
> Is a new kthread necessary? Has the following approach been considered?
> * Make the dm drivers that support rotational zoned storage devices
>   request-based instead of bio-based.

What you are suggesting would be an enormous amount of work (dm-linear,
dm-flakey, dm-error, dm-crypt) to change generic code into DM targets that
would be very specialized for just SMR HDDs. I do not understand why you think
that would be a good idea.

> * Modify blk_mq_get_tag() such that only one tag can be allocated at a
>   time for zoned write requests.

Sure, doing that would limit the number of write requests to zones to 1 at most
at any time, but that would also result in a total loss of control over which
zone write BIO work gets that single tag, meaning that the writes would in the
end be mostly random again, like they are now. So with this solution, I can say
goodbye to the +40% write throughput increase that I am seeing with the kthread.

Also note that this idea of limiting write tags combined with your idea of
using req based DM targets would likely negatively impact dm-crypt performance
as we would lose the ability to encrypt multiple writes in parallel on
different CPUs.

> I think that would be sufficient to serialize zoned writes. Additionally, this
> approach doesn't increase request processing latency
> by forcing a context switch to a kthread.

This point is in my opinion moot because we currently use work items to issue
the write commands. We are scheduling the zone write plugs BIO works in the
submission and completion path, so the context switch overhead is already
there. And would argue that using work items is potentially even more overhead
than using a fixed kthread since the work items need to be assigned to CPUs and
worker threads.

Granted, your point is valid for a QD=1 workload. In this case, I am indeed
introducing a context switch where there is none now. But that is not really
the use case we are looking at here. File system writeback does not happen at
QD=1 per zone. Also, this added overhead does not really matter for HDDs
anyway, and if that is really an issue, the user can enable the legacy zone
write plugging behavior with "echo 0 > /sys/block/sdX/queue/zoned_qd1_writes".

-- 
Damien Le Moal
Western Digital Research