On 2/12/24 17:23, Damien Le Moal wrote: > 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. Replying to myself as I had an idea: 1) Store the zone capacity in a separate array: 4B * nr_zones needed. Storing "0" as a value for a zone in that array would indicate that the zone is conventional. No additional zone bitmap needed. 2) Use a sparse xarray for managing allocated zone write plugs: 64B per allocated zone write plug needed, which for an SMR drive would generally be at most 128 * 64B = 8K. So for an SMR drive with 100,000 zones, that would be a total of 408 KB, instead of the current 1.6 MB. Will try to prototype this to see how performance goes (I am worried about the xarray lookup overhead in the hot path). -- Damien Le Moal Western Digital Research
