mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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¥

  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®