Christoph, On 9/8/17 01:20, Christoph Hellwig wrote: > I'm really worried about how this is tied into the sd driver. > > From a quick look it seems like the only thing you really need in > the scheduler that is done through struct scsi_disk is the > offset + len -> zone number lookup - I'd much rather expose this > from sd upwards and keep the scheduler in the block code. The only things that the scheduler needs are: 1) The zone size and the number of zones of the device (for the bitmaps allocation and offset->zone number conversion). 2) Zone type for the optimization that avoids locking conventional zones. (2) is optional. We can do without, but still really nice to have from a performance perspective as conventional zones tend to be used for storing metadata. So a lot of small random writes is more likely and high queue depth writing would improve performance significantly. For (1), the zone size is known through q->limits.chunk_sectors. But the disk capacity is not known using request_queue only, so the number of zones cannot be calculated... I thought of exporting it through queue limits too, but then stacking of device mappers using ZBC drives becomes a pain as the number of zones needs to be recalculated. The best solution would really be to be able to get a disk capacity given a request queue. Any idea on how to do this ? For optimization (2), there is also the problem that given a request queue, the block_device struct is not known, so it is not possible to issue report zones (granted, the scheduler could build the request directly to do that, but that is really an ugly solution). I did not find any nice solution for either problem, so ended up tying the scheduler to sd since the scsi_disk struct already had all the info needed. > Except for that this looks like a fine approach to me. Thanks. -- Damien Le Moal, Western Digital Research
