From: Eric Dumazet <dada1@cosmosbay.com>
To: David Howells <dhowells@redhat.com>
Cc: "Aubrey Li" <aubreylee@gmail.com>,
"Robin Getz" <rgetz@blackfin.uclinux.org>,
uaca@alumni.uv.es, bryan.wu@analog.com,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
waltje@uwalt.nl.mugnet.org, netdev@vger.kernel.org,
"Andrew Morton" <akpm@osdl.org>,
"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] CONFIG_PACKET_MMAP should depend on MMU
Date: Fri, 20 Apr 2007 11:17:27 +0200 [thread overview]
Message-ID: <20070420111727.fc69d671.dada1@cosmosbay.com> (raw)
In-Reply-To: <2181.1177059532@redhat.com>
On Fri, 20 Apr 2007 09:58:52 +0100
David Howells <dhowells@redhat.com> wrote:
>
> Because kmalloc() may be able to get us a smaller chunk of memory. Actually,
> calling __get_free_pages() might be a better, and then release the excess
> pages.
Interesting, that rings a bell here.
I wonder why we dont use this in alloc_large_system_hash().
(if __get_free_pages(GFP_ATOMIC, order) is used instead of alloc_bootmem() or __vmalloc())
We currently loose 1/4 of space on tcp hash table for example, because sizeof(inet_ehash_bucket) is not a power of 2.
Is it really possible to allocate an order-10 page, then release part of it (say an order-8 subpage) ?
next prev parent reply other threads:[~2007-04-20 9:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-09 3:01 [PATCH] CONFIG_PACKET_MMAP should depend on MMU Aubrey Li
2007-04-09 9:50 ` Wu, Bryan
2007-04-09 15:46 ` Robin Getz
2007-04-10 12:55 ` David Howells
2007-04-10 23:52 ` Robin Getz
2007-04-17 10:36 ` Aubrey Li
2007-04-17 18:30 ` Robin Getz
2007-04-17 19:02 ` David Howells
2007-04-18 15:33 ` David Howells
2007-04-19 0:59 ` Aubrey Li
2007-04-19 9:42 ` David Howells
2007-04-20 4:46 ` Aubrey Li
2007-04-20 7:58 ` David Howells
2007-04-20 8:39 ` Aubrey Li
2007-04-20 8:58 ` David Howells
2007-04-20 9:17 ` Eric Dumazet [this message]
2007-04-20 10:43 ` David Howells
2007-04-20 13:14 ` Aubrey Li
2007-04-09 16:55 ` David Miller
2007-04-09 18:43 ` David Miller
2007-04-09 20:08 ` Robin Getz
2007-04-10 2:00 ` Wu, Bryan
-- strict thread matches above, loose matches on Subject: below --
2006-04-11 4:22 Aubrey
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=20070420111727.fc69d671.dada1@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=aubreylee@gmail.com \
--cc=bryan.wu@analog.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rgetz@blackfin.uclinux.org \
--cc=uaca@alumni.uv.es \
--cc=waltje@uwalt.nl.mugnet.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.