On Mon 20-09-21 11:28:15, Jan Kara wrote: > On Sat 18-09-21 12:58:34, Paolo Valente wrote: > > > Il giorno 15 set 2021, alle ore 15:15, Jan Kara <jack@xxxxxxx> ha scritto: > > > > > > On Tue 31-08-21 11:59:30, Michal Koutný wrote: > > >> Hello Paolo. > > >> > > >> On Fri, Aug 27, 2021 at 12:07:20PM +0200, Paolo Valente <paolo.valente@xxxxxxxxxx> wrote: > > >>> Before discussing your patches in detail, I need a little help on this > > >>> point. You state that the number of scheduler tags must be larger > > >>> than the number of device tags. So, I expected some of your patches > > >>> to address somehow this issue, e.g., by increasing the number of > > >>> scheduler tags. Yet I have not found such a change. Did I miss > > >>> something? > > >> > > >> I believe Jan's conclusions so far are based on "manual" modifications > > >> of available scheduler tags by /sys/block/$dev/queue/nr_requests. > > >> Finding a good default value may be an additional change. > > > > > > Exactly. So far I was manually increasing nr_requests. I agree that > > > improving the default nr_requests value selection would be desirable as > > > well so that manual tuning is not needed. But for now I've left that aside. > > > > > > > Ok. So, IIUC, to recover control on bandwidth you need to > > (1) increase nr_requests manually > > and > > (2) apply your patch > > > > If you don't do (1), then (2) is not sufficient, and viceversa. Correct? > > Correct, although 1) depends on HW capabilities - e.g. for standard SATA > NCQ drive with queue depth of 32, the current nr_requests setting of 256 is > fine and just 2) is enough to recover control. If you run on top of virtio > device or storage controller card with queue depth of 1024, you need to > bump up the nr_requests setting. Paolo, do you have any thoughts about the patches? Any estimate when you can have a look into them? BTW I have sligthly updated version locally which also helps with restoring service differentiation for IO priorities but in principle there's no fundamental difference. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
