From: Corrado Zoccolo <czoccolo@gmail.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH] cfq-iosched: reduce write depth only if sync was delayed
Date: Tue, 8 Dec 2009 21:43:05 +0100 [thread overview]
Message-ID: <4e5e476b0912081243ra071947if9a3edae77fb3861@mail.gmail.com> (raw)
In-Reply-To: <x49ein6nx9k.fsf@segfault.boston.devel.redhat.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 7717 bytes --]
On Tue, Dec 8, 2009 at 1:07 AM, Jeff Moyer <jmoyer@redhat.com> wrote:> Corrado Zoccolo <czoccolo@gmail.com> writes:>>> Hi Jeff, I remember you saw large performance drop on your SAN for>> sequential writes with low_latency=1.  Can you test if Shaohua's and>> this patch fix allow to recover some bandwidth?  I think that enabling>> the queue depth ramp up only if a sync request was delayed should>> disable it for fast hardware like yours, so you should not be seeing>> the slowdown any more.>> Average of 10 runs.  Low latency set to 0:>> Unit information> ================> File size = megabytes> Blk Size  = bytes> Rate    = megabytes per second> CPU%    = percentage of CPU used during the test> Latency  = milliseconds> Lat%    = percent of requests that took longer than X seconds> CPU Eff  = Rate divided by CPU% - throughput per cpu load>> Sequential Reads>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  90.08 94.51%   51.316   10268.25  0.00000  0.00000   95> 2.6.32             8192  65536  16  99.36 199.8%   89.248   13883.81  0.00000  0.00000   50>> Random Reads>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  81.16 85.90%   45.672   5963.19  0.00000  0.00000   94> 2.6.32             8192  65536  16  116.32 230.3%   58.371   6098.36  0.00000  0.00000   51>> Sequential Writes>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  112.17 1085.%   42.623   17114.54  0.00152  0.00000   10> 2.6.32             8192  65536  16  111.26 2117.%   84.964   26480.60  0.03202  0.00000   5>> Random Writes>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  162.48 887.1%   6.106    313.54  0.00000  0.00000   18> 2.6.32             8192  65536  16  156.38 1767.%   14.077   1254.62  0.00000  0.00000   9>>> Average of 10 runs.  Low latency set to 1:>> Unit information> ================> File size = megabytes> Blk Size  = bytes> Rate    = megabytes per second> CPU%    = percentage of CPU used during the test> Latency  = milliseconds> Lat%    = percent of requests that took longer than X seconds> CPU Eff  = Rate divided by CPU% - throughput per cpu load>> Sequential Reads>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  92.23 100.1%   52.119   6920.18  0.00000  0.00000   92> 2.6.32             8192  65536  16  97.88 217.0%   99.691   7453.18  0.00000  0.00000   45>> Random Reads>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  98.70 107.5%   42.994   3409.08  0.00000  0.00000   92> 2.6.32             8192  65536  16  140.41 323.9%   59.616   4525.46  0.00000  0.00000   43>> Sequential Writes>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  112.33 1076.%   42.617   17072.28  0.00076  0.00000   10> 2.6.32             8192  65536  16  111.84 2097.%   85.156   28221.77  0.02976  0.00000   5>> Random Writes>                File  Blk  Num          Avg    Maximum    Lat%   Lat%   CPU> Identifier           Size  Size  Thr  Rate  (CPU%)  Latency   Latency    >2s    >10s   Eff> ---------------------------- ------ ----- ---  ------ ------ --------- -----------  -------- -------- -----> 2.6.32             8192  65536  8  159.33 870.5%   6.469    765.50  0.00000  0.00000   18> 2.6.32             8192  65536  16  141.60 1632.%   15.364   2337.57  0.00000  0.00000   9>>> Cheers,> Jeff>
The numbers look good. Now, there is no penalty in having low_latencyset for sequential writes, and just a small penalty for random ones.The fact that random reads are faster with low_latency set is interesting.Is the test is running with your patched tiobench (so that the numberof random operations is comparable with sequential ones)?
Thanks,Corrado
-- __________________________________________________________________________
dott. Corrado Zoccolo mailto:czoccolo@gmail.comPhD - Department of Computer Science - University of Pisa, Italy--------------------------------------------------------------------------The self-confidence of a warrior is not the self-confidence of the averageman. The average man seeks certainty in the eyes of the onlooker and callsthat self-confidence. The warrior seeks impeccability in his own eyes andcalls that humbleness. Tales of Power - C. Castanedaÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2009-12-08 20:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-04 12:35 Corrado Zoccolo
2009-12-05 11:13 ` Corrado Zoccolo
2009-12-06 10:45 ` Corrado Zoccolo
2009-12-06 10:49 ` Jens Axboe
2009-12-07 14:13 ` Jeff Moyer
2009-12-07 14:41 ` Jens Axboe
2009-12-07 16:45 ` Jeff Moyer
2009-12-07 17:04 ` Vivek Goyal
2009-12-07 17:27 ` Vivek Goyal
2009-12-07 18:03 ` Vivek Goyal
2009-12-08 0:07 ` Jeff Moyer
2009-12-08 20:43 ` Corrado Zoccolo [this message]
2009-12-09 18:09 ` Jeff Moyer
2009-12-11 17:15 ` Corrado Zoccolo
2009-12-11 17:50 ` Jeff Moyer
2009-12-18 15:32 ` Jeff Moyer
2009-12-18 21:03 ` Corrado Zoccolo
2009-12-08 18:00 ` Jeff Moyer
2009-12-08 20:46 ` Corrado Zoccolo
2009-12-09 18:16 ` Jeff Moyer
2009-12-09 19:05 ` Jens Axboe
2009-12-09 19:45 Corrado Zoccolo
2009-12-09 19:51 ` Jeff Moyer
2009-12-09 19:54 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e5e476b0912081243ra071947if9a3edae77fb3861@mail.gmail.com \
--to=czoccolo@gmail.com \
--cc=jens.axboe@oracle.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®