public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "Tang, Yu" <yu.tang@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [Linux-ia64] kmalloc() size-limitation
Date: Tue, 15 Jan 2002 07:56:16 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590698805829@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805828@msgid-missing>

if I am not missing something, kmalloc is SLAB based on _get_free_pages
nowadays,  and alloc_pages() is based on _get_free_pages directly.  you may
get the more limitations than alloc_pages(). the reason for choosing kmalloc
mainly, is that it makes less fragments when allocing and freeing memories
that's not large as pages.

-----Original Message-----
From: Christian Hildner [mailto:christian.hildner@hob.de]
Sent: 2002年1月15日 15:15
To: davidm@hpl.hp.com; linux ia64 kernel list; LKML
Subject: [Linux-ia64] kmalloc() size-limitation


David,

you proposed me to use alloc_pages() instead of kmalloc() in order to get
memory bigger than the
128K limit of the kmalloc() call. But even driver-developers don't want to
handle with the page
struct unless this is unavoidable. Which are the disadvantages of increasing
the size limit of
kmalloc() to 256K, 512K or 1M since machines are getting bigger and 64Bit
machines break with
current memory limitations?

Since kmalloc() is implemented in the non arch specific part this also goes
to the lkml.

Christian


_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64


  reply	other threads:[~2002-01-15  7:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-15  7:14 [Linux-ia64] kmalloc() size-limitation Christian Hildner
2002-01-15  7:56 ` Tang, Yu [this message]
2002-02-04 21:16 ` Jes Sorensen

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=marc-linux-ia64-105590698805829@msgid-missing \
    --to=yu.tang@intel.com \
    --cc=linux-ia64@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox