All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jan Kara <jack@suse.cz>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Allow setting of number of raw devices as a module parameter
Date: Sat, 30 Apr 2011 08:47:33 -0700	[thread overview]
Message-ID: <20110430154733.GA21893@suse.de> (raw)
In-Reply-To: <20110430164141.55d0ef0a@lxorguk.ukuu.org.uk>

On Sat, Apr 30, 2011 at 04:41:41PM +0100, Alan Cox wrote:
> > > A large vmalloc array is very antisocial on a 32bit x86 box. It looks
> > > like almost all of it would become sane if there was an array of pointers
> > > to raw devices and the devices were initially allocated on need (even if
> > > for now only recovered on rmmod)
> > 
> > In practice, we've never seen a problem with this[1].  Machines that
> > want thousands of raw devices have plenty of memory to handle this
> > situation.
> > 
> > I doubt adding the complexity of dynamically allocating the devices
> > as-needed is worth it for the very few systems that ever use this
> > driver, compounded with the fact that we keep saying that this code
> > isn't to be used by "normal" people anyway.
> 
> That's no excuse for sloppy code. Making it an array populated on demand
> is an improvement for everyone, making it vmalloc hurts every access (in
> TLB misses for one as well as vmalloc overhead).
> 
> I note two of us immediately made the same observation. Doing it
> basically right (array of pointers) is easy. Doing the full works with a
> hash for the lookups is a bit harder and that I would agree is overkill.

Ah, ok, I was thinking of the latter, I'll work on implementing the
former next week, unless Jan wants to do it instead?

thanks for the review,

greg k-h

  reply	other threads:[~2011-04-30 15:46 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28 22:24 Allow setting of number of raw devices as a module parameter Jan Kara
2011-04-29 23:19 ` Greg KH
2011-04-29 23:28 ` Andrew Morton
2011-04-30  0:07   ` Greg KH
2011-04-30  5:09     ` Dave Jones
2011-04-30  5:42       ` Greg KH
2011-04-30 10:29   ` Alan Cox
2011-04-30 15:34     ` Greg KH
2011-04-30 15:41       ` Alan Cox
2011-04-30 15:47         ` Greg KH [this message]
2011-05-02 19:22         ` Jan Kara
2011-05-03  9:42           ` Alan Cox
2011-04-30 12:15 ` Arnd Bergmann
2011-05-02 19:39   ` Jan Kara
2011-05-02 19:44     ` Arnd Bergmann
2011-05-02 21:11       ` Jan Kara
2011-05-03 10:55         ` Arnd Bergmann
2011-05-03 16:26           ` Jan Kara
2011-05-03 17:30             ` Arnd Bergmann

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=20110430154733.GA21893@suse.de \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    /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.