| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Sep 2009 13:48:09 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Mike Galbraith <efault@....de>
Cc: Jens Axboe <jens.axboe@...cle.com>,
Ulrich Lukas <stellplatz-nr.13a@...enparkplatz.de>,
linux-kernel@...r.kernel.org,
containers@...ts.linux-foundation.org, dm-devel@...hat.com,
nauman@...gle.com, dpshah@...gle.com, lizf@...fujitsu.com,
mikew@...gle.com, fchecconi@...il.com, paolo.valente@...more.it,
ryov@...inux.co.jp, fernando@....ntt.co.jp, jmoyer@...hat.com,
dhaval@...ux.vnet.ibm.com, balbir@...ux.vnet.ibm.com,
righi.andrea@...il.com, m-ikeda@...jp.nec.com, agk@...hat.com,
akpm@...ux-foundation.org, peterz@...radead.org,
jmarchan@...hat.com, torvalds@...ux-foundation.org, mingo@...e.hu,
riel@...hat.com
Subject: Re: IO scheduler based IO controller V10
On Mon, Sep 28, 2009 at 06:04:08AM +0200, Mike Galbraith wrote:
> On Sun, 2009-09-27 at 20:16 +0200, Mike Galbraith wrote:
> > On Sun, 2009-09-27 at 18:42 +0200, Jens Axboe wrote:
>
> > I'll give it a shot first thing in the A.M.
>
> > > diff --git a/block/elevator.c b/block/elevator.c
> > > index 1975b61..d00a72b 100644
> > > --- a/block/elevator.c
> > > +++ b/block/elevator.c
> > > @@ -497,9 +497,17 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
> > > * See if our hash lookup can find a potential backmerge.
> > > */
> > > __rq = elv_rqhash_find(q, bio->bi_sector);
> > > - if (__rq && elv_rq_merge_ok(__rq, bio)) {
> > > - *req = __rq;
> > > - return ELEVATOR_BACK_MERGE;
> > > + if (__rq) {
> > > + /*
> > > + * If requests are queued behind this one, disallow merge. This
> > > + * prevents streaming IO from continually passing new IO.
> > > + */
> > > + if (elv_latter_request(q, __rq))
> > > + return ELEVATOR_NO_MERGE;
> > > + if (elv_rq_merge_ok(__rq, bio)) {
> > > + *req = __rq;
> > > + return ELEVATOR_BACK_MERGE;
> > > + }
> > > }
> > >
> > > if (e->ops->elevator_merge_fn)
>
> - = virgin tip v2.6.31-10215-ga3c9602
> + = with patchlet
> Avg
> dd pre 67.4 70.9 65.4 68.9 66.2 67.7-
> 65.9 68.5 69.8 65.2 65.8 67.0- Avg
> 70.4 70.3 65.1 66.4 70.1 68.4- 67.7-
> 73.1 64.6 65.3 65.3 64.9 66.6+ 65.6+ .968
> 63.8 67.9 65.2 65.1 64.4 65.2+
> 64.9 66.3 64.1 65.2 64.8 65.0+
> perf stat 8.66 16.29 9.65 14.88 9.45 11.7-
> 15.36 9.71 15.47 10.44 12.93 12.7-
> 10.55 15.11 10.22 15.35 10.32 12.3- 12.2-
> 9.87 7.53 10.62 7.51 9.95 9.0+ 9.1+ .745
> 7.73 10.12 8.19 11.87 8.07 9.1+
> 11.04 7.62 10.14 8.13 10.23 9.4+
> dd post 63.4 60.5 66.7 64.5 67.3 64.4-
> 64.4 66.8 64.3 61.5 62.0 63.8-
> 63.8 64.9 66.2 65.6 66.9 65.4- 64.5-
> 60.9 63.4 60.2 63.4 65.5 62.6+ 61.8+ .958
> 63.3 59.9 61.9 62.7 61.2 61.8+
> 60.1 63.7 59.5 61.5 60.6 61.0+
>
Hmm.., so close to 25% reduction on average in completion time of konsole.
But this is in presece of writer. Does this help even in presence of 1 or
more sequential readers going?
So here latency seems to be coming from three sources.
- Wait in CFQ before request is dispatched (only in case of competing seq readers).
- seek latencies
- latencies because of bigger requests are already dispatched to disk.
So limiting the size of request will help with third factor but not with first
two factors and here seek latencies seem to be the biggest contributor.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists