All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Erik Jacobson <erikj@subway.americas.sgi.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: 2.6 /proc/interrupts fails on systems with many CPUs
Date: Tue, 11 Nov 2003 10:24:46 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0311111019210.30657-100000@home.osdl.org> (raw)
In-Reply-To: <9710000.1068573723@flay>


On Tue, 11 Nov 2003, Martin J. Bligh wrote:
> 
> 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.

		Linus


  reply	other threads:[~2003-11-11 18:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-11 17:21 2.6 /proc/interrupts fails on systems with many CPUs Erik Jacobson
2003-11-11 17:29 ` Randy.Dunlap
2003-11-11 17:51 ` Robert Love
2003-11-11 18:02 ` Martin J. Bligh
2003-11-11 18:24   ` Linus Torvalds [this message]
2003-11-11 18:57     ` Martin J. Bligh
2003-11-11 18:36       ` Linus Torvalds
2003-11-11 20:14     ` Anton Blanchard
2003-11-11 22:41       ` Martin J. Bligh
2003-11-11 22:32         ` Zwane Mwaikambo
2004-01-27  4:12     ` radeonfb problems with 2.6.2-rc2 Roland Dreier
2003-11-11 18:17 ` 2.6 /proc/interrupts fails on systems with many CPUs Linus Torvalds
2003-11-11 18:22   ` viro
2003-11-11 20:15     ` Jonathan Corbet
2003-11-11 18:32   ` Randy.Dunlap
2003-11-11 19:19 ` Anton Blanchard
2003-11-11 18:15 Manfred Spraul
     [not found] <BF1FE1855350A0479097B3A0D2A80EE0013B1188@hdsmsx402.hd.intel.com>
2003-11-11 19:55 ` Len Brown
2003-11-11 23:37   ` Erlend Aasland
2003-11-12  2:35     ` Martin J. Bligh

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=Pine.LNX.4.44.0311111019210.30657-100000@home.osdl.org \
    --to=torvalds@osdl.org \
    --cc=erikj@subway.americas.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.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 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.