On 2/11/24 12:40, Bart Van Assche wrote: > On 2/9/24 16:06, Damien Le Moal wrote: >> On 2/10/24 04:36, Bart Van Assche wrote: >>> 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. > > Interesting. The zoned devices I'm working with try to keep data in memory > for all zones that are neither empty nor full and hence impose an upper limit > on the number of open zones. > >> 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). > > Hmm ... since the xarray data structure supports RCU I think that locking the > entire xarray is only required if the zone condition changes from empty into > not empty or from neither empty nor full into full? > > For the use cases I'm interested in a hash table implementation that supports > RCU-lookups probably will work better than an xarray. I think that the hash > table implementation in <linux/hashtable.h> supports RCU for lookups, insertion > and removal. I spent some time digging into this and also revisiting the possibility of using an xarray. Conclusion is that this does not work well, at least in no way not better than what I did, and most of the time much worse. The reason is that we need at the very least to keep this information around: 1) If the zone is conventional or not 2) The zone capacity of sequential write required zones Unless we keep this information, a report zone would be needed before starting writing to a zone that does not yet have a zone write plug allocated. (1) and (2) above can be trivially combined into a single 32-bits value. But that value must exist for all zones. So at the very least, we need nr_zones * 4B of memory allocated at all time. For such case (i.e. non-sparse structure), xarray or hash table would be more costly in memory than a simple static array. Given that we want to allocate/free zone write plugs dynamically as needed, we essentially need an array of pointers, so 8B * nr_zones for the base structure. >From there, ideally, we should be able to use rcu to safely dereference/modify the array entries. However, static arrays are not supported by the rcu code from what I read. Given this, my current approach that uses 16B per zone is the next best thing I can think of without introducing a single lock for modifying the array entries. If you have any other idea, please share. -- Damien Le Moal Western Digital Research
