Re: [PATCH 3/3] bfq: Use only idle IO periods for think time calculations

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

 



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?

								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