linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: linux-raid@vger.kernel.org
Cc: neilb@suse.de, axboe@kernel.dk
Subject: [patch 0/3 v3] Optimize raid1 read balance for SSD
Date: Mon, 02 Jul 2012 09:08:40 +0800	[thread overview]
Message-ID: <20120702010840.197370335@kernel.org> (raw)

raid1 read balance is an important algorithm to make read performance optimal.
It's a distance based algorithm, eg, for each request dispatch, choose disk
whose last finished request is close the request. This is great for hard disk.
But SSD has some special characteristics:

1. nonrotational. Distance means nothing for SSD, though merging small rquests
to big request is still optimal for SSD. If no merge, distributing rquests to
raid disks as more as possible is more optimal.

2. Getting too big request isn't always optimal. For hard disk, compared to
spindle move, data transfer overhead is trival, so we always prefer bigger
request. In SSD, request size exceeds specific value, performance isn't always
increased with request size increased.  An example is readahead. If readahead
merges too big request and causes some disks idle, the performance is less
optimal than that when all disks are busy and running small requests.

The patches try to address the issues.

V3:
makes the algorithm for the first issue work for hard disk and SSD mixed raid
as suggested by Neil. The algorithm for the second issue only applies to SSD,
because in my test it degrades performance for hard disk raid or hard disk/SSD
mixed raid.

V1->V2:
rebase to latest kernel.

Thanks,
Shaohua

             reply	other threads:[~2012-07-02  1:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-02  1:08 Shaohua Li [this message]
2012-07-02  1:08 ` [patch 1/3 v3] raid1: make sequential read detection per disk based Shaohua Li
2012-07-04  5:38   ` NeilBrown
2012-07-02  1:08 ` [patch 2/3 v3] raid1: read balance chooses idlest disk for SSD Shaohua Li
2012-07-02  2:13   ` Roberto Spadim
2012-07-02  3:02     ` Shaohua Li
2012-07-02  3:57       ` Roberto Spadim
2012-07-02  4:33         ` Roberto Spadim
2012-07-02  4:31       ` Roberto Spadim
2012-07-02  4:36         ` Roberto Spadim
2012-07-04  5:45   ` NeilBrown
2012-07-02  1:08 ` [patch 3/3 v3] raid1: prevent merging too large request Shaohua Li
2012-07-04  5:59   ` NeilBrown
2012-07-04  8:01     ` Shaohua Li

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=20120702010840.197370335@kernel.org \
    --to=shli@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).