Re: [PATCH 25/26] block: Reduce zone write plugging memory usage

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

On 2/10/24 04:36, Bart Van Assche wrote:
> On 2/8/24 19:58, Damien Le Moal wrote:
>> We still need to keep in memory the write pointer offset of zones that are not
>> being actively written to but have been previously partially written. So I do
>> not see how excluding empty and full zones from that tracking simplifies
>> anything at all. And the union of wp offset+zone capacity with a pointer to the
>> active zone plug structure is not *that* complicated to handle...
> 
> Multiple zoned storage device have 1000 or more zones. The number of partially

Try multiplying that by 100... 28TB SMR drives have 104000 zones.

> written zones is typically less than 10. Hence, tracking the partially written

That is far from guaranteed, especially with devices that have no active zone
limits like SMR drives.

> zones only will result in significantly less memory being used, fewer CPU cache
> misses and fewer MMU TLB lookup misses. I expect that this will matter since the
> zone information data structure will be accessed every time a zoned write bio is
> processed.

May be. The performance numbers I have suggest that this is not an issue.

But in any case, what exactly is your idea here ? Can you actually suggest
something ? Are you suggesting that a sparse array of zone plugs be used, with
an rb-tree or an xarray ? If that is what you are thinking, I can already tell
you that this is the first thing I tried to do. Early versions of this work used
a sparse xarray of zone plugs. But the problem with such approach is that it is
a lot more complicated and there is a need for a single lock to manage that
structure (which is really not good for performance).

Hence this series which used a statically allocated array of zone plugs to
simplify things. Overall, this series is a significant change to the zone write
path and I wanted something simple/reliable that is not a nightmare to debug and
test. I believe that an xarray based optimization can be re-tried as an
incremental change on top of this series. The nice thing about it is that the
API should not need to change, meaning that all changes can be contained within
blk-zone.c.

But I may be missing entirely your point. So clarify please.

-- 
Damien Le Moal
Western Digital Research