From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: NeilBrown <neilb@suse.de>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
linux-raid@vger.kernel.org
Subject: Re: stripe cache question
Date: Sat, 26 Feb 2011 11:21:28 +0100 [thread overview]
Message-ID: <20110226102128.GA15074@lazy.lzy> (raw)
In-Reply-To: <20110225145125.69dd4b9d@notabene.brown>
On Fri, Feb 25, 2011 at 02:51:25PM +1100, NeilBrown wrote:
> On Thu, 24 Feb 2011 22:06:43 +0100 Piergiorgio Sartor
> <piergiorgio.sartor@nexgo.de> wrote:
>
> > Hi all,
> >
> > few posts ago was mentioned that the unit of the stripe
> > cache are "pages per device", usually 4K pages.
> >
> > Questions:
> >
> > 1) Does "device" means raid (md) device or component
> > device (HDD)?
>
> component device.
> In drivers/md/raid5.[ch] there is a 'struct stripe_head'.
> It holds one page per component device (ignoring spares).
> Several of these comprise the 'cache'. The 'size' of the cache is the number
> oof 'struct stripe_head' and associated pages that are allocated.
>
>
> >
> > 2) The max possible value seems to be 32768, which
> > means, in case of 4K page per md device, a max of
> > 128MiB of RAM.
> > Is this by design? Would it be possible to increase
> > up to whatever is available?
>
> 32768 is just an arbitrary number. It is there in raid5.c and is easy to
> change (for people comfortable with recompiling their kernels).
Ah! I found it. Maybe, considering currently
available memory you should think about incresing
it to, for example, 128K or 512K.
> I wanted an upper limit because setting it too high could easily cause your
> machine to run out of memory and become very sluggish - or worse.
>
> Ideally the cache should be automatically sized based on demand and memory
> size - with maybe just a tunable to select between "use a much memory as you
> need - within reason" verse "use a little memory as you can manage with".
>
> But that requires thought and design and code and .... it just never seemed
> like a priority.
You're a bit contraddicting your philosopy of
"let's do the smart things in user space"... :-)
IMHO, if really necessary, it could be enough to
have this "upper limit" avaialable in sysfs.
Then user space can decide what to do with it.
For example, at boot the amount of memory is checked
and the upper limit set.
I see a duplication here, maybe better just remove
the upper limit and let user space to deal with that.
bye,
--
piergiorgio
next prev parent reply other threads:[~2011-02-26 10:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-24 21:06 stripe cache question Piergiorgio Sartor
2011-02-25 3:51 ` NeilBrown
2011-02-26 10:21 ` Piergiorgio Sartor [this message]
2011-02-27 4:43 ` NeilBrown
2011-02-27 11:37 ` Piergiorgio Sartor
2011-03-06 20:08 ` Piergiorgio Sartor
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=20110226102128.GA15074@lazy.lzy \
--to=piergiorgio.sartor@nexgo.de \
--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).