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