Re: Allow setting of number of raw devices as a module parameter

[Jan Kara <jack@suse.cz>]

On Sat 30-04-11 16:41:41, 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.
  Alan, I might be missing something but is there a significant advantage
in creating the array of pointers? Note that struct raw_device_data which
is what the array is from is:
struct raw_device_data {
        struct block_device *binding;
        int inuse;
};
So 16 bytes on 64-bit arch. You can make it 8 bytes by the
array-of-pointers idea but people requesting this feature want to run with
8192 or even 16384 raw devices in the system (yes, they might be insane).
That gives you 16 to 32 pages for array of pointers which seems too much
to me for kmalloc() anyway.

So if people don't like vmalloc() (which I can understand), then I see no
other option than dynamically allocating struct raw_device_data.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR