From: Frank Mayhar <fmayhar@google.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Mikulas Patocka <mpatocka@redhat.com>,
device-mapper development <dm-devel@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: dm: Make MIN_IOS, et al, tunable via sysctl.
Date: Tue, 20 Aug 2013 16:14:22 -0700 [thread overview]
Message-ID: <1377040462.24869.70.camel@bobble.lax.corp.google.com> (raw)
In-Reply-To: <20130820222439.GA5883@redhat.com>
On Tue, 2013-08-20 at 18:24 -0400, Mike Snitzer wrote:
> Mikulas' point is that you cannot reduce the size to smaller than 1.
> And aside from rq-based DM, 1 is sufficient to allow for forward
> progress even when memory is completely consumed.
>
> A patch that simply changes them to 1 but makes the rq-based DM
> mempool's size configurable should actually be fine.
So you're saying that I should submit a patch to drop the pool size for
BIO_BASED to 1 and make the pool size for REQUEST_BASED configurable?
At the moment, in dm.c the former is hardcoded to 16 and the latter is
set via MIN_IOS (currently 256). There's also io_pool, a slab pool,
which is also set via MIN_IOS.
How does this relate to the rest of the DM modules? Mpath also sets
MIN_IOS to 256 and creates a slab pool from that, and there are a number
of hardcoded constants in dm-io (MIN_IOS and MIN_BIOS), dm-snap
(MIN_IOS), dm-crypt (MIN_IOS and MIN_POOL_PAGES), dm-bufio
(DM_BUFIO_HASH_BITS, which is allocated via vmalloc per client) and
dm-verity (DM_VERITY_MEMPOOL_SIZE, which is allocated per device).
For the most part I can't imagine that people will want to change these
from their defaults, but when someone does need to change one of these,
they need to do so badly and there's currently no good way to do that
besides hacking the source and building a new kernel.
By the way, I do appreciate the advice. I'm just trying to clear up
confusion on my part, make sure that our needs are met and, while I'm at
it, make things a bit better for those who come after me.
--
Frank Mayhar
310-460-4042
next prev parent reply other threads:[~2013-08-20 23:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 17:48 [PATCH] " Frank Mayhar
2013-08-13 16:41 ` Frank Mayhar
2013-08-16 22:58 ` Frank Mayhar
2013-08-17 12:30 ` [dm-devel] " Alasdair G Kergon
2013-08-19 13:40 ` Mike Snitzer
2013-08-19 15:04 ` Frank Mayhar
2013-08-19 14:00 ` Mike Snitzer
2013-08-19 17:54 ` [dm-devel] " Frank Mayhar
2013-08-19 18:15 ` Mike Snitzer
2013-08-20 21:44 ` [dm-devel] " Mikulas Patocka
2013-08-20 21:52 ` Frank Mayhar
2013-08-20 21:41 ` Mikulas Patocka
2013-08-20 21:22 ` [dm-devel] [PATCH] " Mikulas Patocka
2013-08-20 21:28 ` Frank Mayhar
2013-08-20 21:47 ` Mikulas Patocka
2013-08-20 21:57 ` Frank Mayhar
2013-08-20 22:24 ` Mike Snitzer
2013-08-20 22:52 ` Mikulas Patocka
2013-08-20 23:14 ` Frank Mayhar [this message]
2013-08-26 14:28 ` Mikulas Patocka
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=1377040462.24869.70.camel@bobble.lax.corp.google.com \
--to=fmayhar@google.com \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome