All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
To: dm-devel@redhat.com, malahal@us.ibm.com,
	christophe.varoqui@gmail.com, Mike Snitzer <snitzer@redhat.com>
Subject: Re: multipath: change the DEFAULT_MINIO for the request based multipath
Date: Tue, 25 Jan 2011 17:56:00 +0900	[thread overview]
Message-ID: <4D3E9020.6010009@ce.jp.nec.com> (raw)
In-Reply-To: <20110121173930.GB20278@us.ibm.com>

Hi,

On 01/22/11 02:39, Malahal Naineni wrote:
> Christophe Varoqui [christophe.varoqui@gmail.com] wrote:
>>
>>> I'm not following why we'd need a different configuration parameter.
>>> It is just that the default rr_min_io that would be used would be
>>> conditional on the multipath target version being >= 1.1.0.
>>>
>> Defaults are layered. For current minio, we have :
>> [1] one top level default (hardcoded, superseded by config)
>> [2] per hardware default (hardcoded, superseded by config)
>> [3] per multipath value (none hardcoded, defined by config)
>>
>> You suggest multipath-tools to adapt only the top level minio default
>> depending on dm-rq availability [1], but what of the hwtable defaults
>> [2] ? Should we provide vendors with a way to describe a with-rq minio
>> default *and* a without-rq minio default (a new parameter in the hwentry
>> struct) ? If so, we should also provide a new config file keyword to
>> override this new hwentry parameter hardcoded value ... then the
>> reasoning cascades to the mpentry struct minio setting [3].
>>
>> Actually, [1] is hardly the common case : only unknown hardware resort
>> to these defaults.

Do we really need [2]?

Currently, there seem only 3 minio values in per-hardware default:
  - 1000 (DEFAULT_MINIO)
  - 128
  - 100

I think both 128 and 100 are based on that, in many systems/cases,
max request size (max_sectors) is 512KB and BIO submission
is done in page-size unit (4KB).

If there isn't strong reason for the current default (1000)
(and I think there isn't), it seems we can remove [2]
after changing the default to 128 (or 100).

>> Is my reasoning flawed ?
> 
> I don't think so. Your reasoning is right. How about this:
> 
> 1. Set DEFAULT_MINIO to -1
> 2. If bio based mapping and the value is -1, set it to 1000
>    (DEFAULT_BIO_MINIO)
> 3. If request based mapping, set it to DEFAULT_REQUEST_MINIO.
> 
> Note that devices can't have individual hardware default for request
> based mappings in this method and I think that should be OK. They are
> allowed to individual hardware based default for BIO based mappings as
> they have now. I will code it up if everyone agrees.

Does it mean users can't change rr_min_io value for request-based dm?
I suspect it is possible that someone wants to set non-default
value to minio for request-based dm.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation

  reply	other threads:[~2011-01-25  8:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19 21:30 [PATCH] [RFC] multipath: change the DEFAULT_MINIO for the request based multipath Malahal Naineni
2011-01-20  7:32 ` Hannes Reinecke
2011-01-20 16:07   ` Mike Snitzer
2011-01-21  7:03     ` Jun'ichi Nomura
2011-01-21  8:47       ` Christophe Varoqui
2011-01-21 14:12         ` Mike Snitzer
2011-01-21 14:46           ` Christophe Varoqui
2011-01-21 17:39             ` Malahal Naineni
2011-01-25  8:56               ` Jun'ichi Nomura [this message]
2011-01-26  2:23                 ` Malahal Naineni
2011-01-26 17:27                   ` nishant mungse
2011-01-27 15:16                     ` nishant mungse
2011-01-31 23:53                   ` Christophe Varoqui
2011-02-01  2:21                     ` Malahal Naineni
2011-02-01  3:13                       ` Mike Snitzer
2011-02-01  8:14                         ` Malahal Naineni
2011-02-01  8:13                     ` Malahal Naineni
2011-02-01  9:00                       ` Christophe Varoqui
2011-02-01  9:51                         ` Malahal Naineni
2011-01-21 13:26       ` Mike Snitzer

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=4D3E9020.6010009@ce.jp.nec.com \
    --to=j-nomura@ce.jp.nec.com \
    --cc=christophe.varoqui@gmail.com \
    --cc=dm-devel@redhat.com \
    --cc=malahal@us.ibm.com \
    --cc=snitzer@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.