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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
