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
next prev parent reply other threads:[~2002-01-15 7:56 UTC|newest]
Thread overview: 7+ 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
[not found] <3C3D6A89.27EAA4C7@hob.de>
[not found] ` <15421.61910.163437.45726@napali.hpl.hp.com>
[not found] ` <3C3ED5E7.8BA479B7@hob.de>
[not found] ` <15423.5404.65155.924018@napali.hpl.hp.com>
[not found] ` <3C43D6EC.74B4EC85@hob.de>
2002-02-04 21:16 ` Jes Sorensen
2002-02-05 6:51 ` Christian Hildner
2002-02-07 15:47 ` Jes Sorensen
2002-02-08 7:23 ` Christian Hildner
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 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.