Re: 2.6 /proc/interrupts fails on systems with many CPUs

[Martin J. Bligh]

>> I think it'd make more sense to only use vmalloc when it's explicitly 
>> too big for kmalloc - or simply switch on num_online_cpus > 100 or 
>> whatever a sensible cutoff is (ie nobody but you would ever see this ;-))
> 
> No, please please please don't do these things.
> 
> vmalloc() is NOT SOMETHING YOU SHOULD EVER USE! It's only valid for when
> you _need_ a big array, and you don't have any choice. It's slow, and it's
> a very restricted resource: it's a global resource that is literally
> restricted to a few tens of megabytes. It should be _very_ carefully used.
> 
> There are basically no valid new uses of it. There's a few valid legacy
> users (I think the file descriptor array), and there are some drivers that
> use it (which is crap, but drivers are drivers), and it's _really_ valid
> only for modules. Nothing else.
> 
> Basically: if you think you need more memory than a kmalloc() can give,
> you need to re-organize your data structures. To either not need a big 
> area, or to be able to allocate it in chunks.

OK, I was actually trying to avoid the use of vmalloc, instead of the 
unconditional conversion to vmalloc, which is what the original patch did ;-)

But you are, of course, correct - in this case, it should be easy to use 
the seq_file stuff to do it in smaller chunks, and use a smaller buffer.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/