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
