> Il giorno 2 set 2020, alle ore 17:17, Jan Kara <jack@xxxxxxx> ha scritto: > > On Wed 26-08-20 15:54:19, Jan Kara wrote: >> On Mon 27-07-20 09:35:15, Jan Kara wrote: >>> On Wed 22-07-20 11:13:28, Paolo Valente wrote: >>>>> a) I don't think adding these samples to statistics helps in any way (you >>>>> cannot improve the prediction power of the statistics by including in it >>>>> some samples that are not directly related to the thing you try to >>>>> predict). And think time is used to predict the answer to the question: If >>>>> bfq queue becomes idle, how long will it take for new request to arrive? So >>>>> second and further requests are simply irrelevant. >>>>> >>>> >>>> Yes, you are super right in theory. >>>> >>>> Unfortunately this may not mean that your patch will do only good, for >>>> the concerns in my previous email. >>>> >>>> So, here is a proposal to move forward: >>>> 1) I test your patch on my typical set of >>>> latency/guaranteed-bandwidth/total-throughput benchmarks >>>> 2) You test your patch on a significant set of benchmarks in mmtests >>>> >>>> What do you think? >>> >>> Sure, I will queue runs for the patches with mmtests :). >> >> Sorry it took so long but I've hit a couple of technical snags when running >> these tests (plus I was on vacation). So I've run the tests on 4 machines. >> 2 with rotational disks with NCQ, 2 with SATA SSD. Results are mostly >> neutral, details are below. >> >> For dbench, it seems to be generally neutral but the patches do fix >> occasional weird outlier which are IMO caused exactly by bugs in the >> heuristics I'm fixing. Things like (see the outlier for 4 clients >> with vanilla kernel): >> >> vanilla bfq-waker-fixes >> Amean 1 32.57 ( 0.00%) 32.10 ( 1.46%) >> Amean 2 34.73 ( 0.00%) 34.68 ( 0.15%) >> Amean 4 199.74 ( 0.00%) 45.76 ( 77.09%) >> Amean 8 65.41 ( 0.00%) 65.47 ( -0.10%) >> Amean 16 95.46 ( 0.00%) 96.61 ( -1.21%) >> Amean 32 148.07 ( 0.00%) 147.66 ( 0.27%) >> Amean 64 291.17 ( 0.00%) 289.44 ( 0.59%) >> >> For pgbench and bonnie, patches are neutral for all the machines. >> >> For reaim disk workload, patches are mostly neutral, just on one machine >> with SSD they seem to improve XFS results and worsen ext4 results. But >> results look rather noisy on that machine so it may be just a noise... >> >> For parallel dd(1) processes reading from multiple files, results are also >> neutral all machines. >> >> For parallel dd(1) processes reading from a common file, results are also >> neutral except for one machine with SSD on XFS (ext4 was fine) where there >> seems to be consistent regression for 4 and more processes: >> >> vanilla bfq-waker-fixes >> Amean 1 393.30 ( 0.00%) 391.02 ( 0.58%) >> Amean 4 443.88 ( 0.00%) 517.16 ( -16.51%) >> Amean 7 599.60 ( 0.00%) 748.68 ( -24.86%) >> Amean 12 1134.26 ( 0.00%) 1255.62 ( -10.70%) >> Amean 21 1940.50 ( 0.00%) 2206.29 ( -13.70%) >> Amean 30 2381.08 ( 0.00%) 2735.69 ( -14.89%) >> Amean 48 2754.36 ( 0.00%) 3258.93 ( -18.32%) >> >> I'll try to reproduce this regression and check what's happening... >> >> So what do you think, are you fine with merging my patches now? > > Paolo, any results from running your tests for these patches? I'd like to > get these mostly obvious things merged so that we can move on... > Hi, sorry again for my delay. Tested this too, at last. No regression. So gladly Acked-by: Paolo Valente <paolo.valente@xxxxxxxxxx> And thank you very much for your contributions and patience, Paolo > Honza > -- > Jan Kara <jack@xxxxxxxx> > SUSE Labs, CR