Re: [PATCH 0/8 v3] bfq: Limit number of allocated scheduler tags per cgroup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Il giorno 25 ott 2021, alle ore 13:14, Jan Kara <jack@xxxxxxx> ha scritto:
> 
> On Mon 25-10-21 09:58:11, Paolo Valente wrote:
>>> Il giorno 7 ott 2021, alle ore 18:33, Paolo Valente <paolo.valente@xxxxxxxxxx> ha scritto:
>>>> Il giorno 6 ott 2021, alle ore 19:31, Jan Kara <jack@xxxxxxx> ha scritto:
>>>> 
>>>> Hello!
>>>> 
>>>> Here is the third revision of my patches to fix how bfq weights apply on cgroup
>>>> throughput and on throughput of processes with different IO priorities. Since
>>>> v2 I've added some more patches so that now IO priorities also result in
>>>> service differentiation (previously they had no effect on service
>>>> differentiation on some workloads similarly to cgroup weights). The last patch
>>>> in the series still needs some work as in the current state it causes a
>>>> notable regression (~20-30%) with dbench benchmark for large numbers of
>>>> clients. I've verified that the last patch is indeed necessary for the service
>>>> differentiation with the workload described in its changelog. As we discussed
>>>> with Paolo, I have also found out that if I remove the "waker has enough
>>>> budget" condition from bfq_select_queue(), dbench performance is restored
>>>> and the service differentiation is still good. But we probably need some
>>>> justification or cleaner solution than just removing the condition so that
>>>> is still up to discussion. But first seven patches already noticeably improve
>>>> the situation for lots of workloads so IMO they stand on their own and
>>>> can be merged regardless of how we go about the last patch.
>>>> 
>>> 
>>> Hi Jan,
>>> I have just one more (easy-to-resolve) doubt: you seem to have tested
>>> these patches mostly on the throughput side.  Did you run a
>>> startup-latency test as well?  I can run some for you, if you prefer
>>> so. Just give me a few days.
>>> 
>> 
>> We are finally testing your patches a little bit right now, for
>> regressions with our typical benchmarks ...
> 
> Hum, strange I didn't get your previous email about benchmarks. You're
> right I didn't run startup-latency AFAIR. Now that you've started them,
> probably there's no big point in me queuing them as well. So thanks for
> the benchmarking :)
> 

Hi Jan,
we have executed a lot of benchmarking, on various hardware.  No
regression found!

So, thank you very much for this important contribution, and:

Acked-by: Paolo Valente <paolo.valente@xxxxxxxxxx>

> 								Honza
> -- 
> Jan Kara <jack@xxxxxxxx>
> SUSE Labs, CR





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux