From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Try to avoid a pessimistic vmalloc() recursion
Date: Tue, 10 Oct 2006 02:25:17 +1000 [thread overview]
Message-ID: <452A77ED.6070001@yahoo.com.au> (raw)
In-Reply-To: <200610091647.55184.dada1@cosmosbay.com>
Eric Dumazet wrote:
> __vmalloc_area_node() is a litle bit pessimist when allocating space for
> storing struct page pointers.
>
> When allocating more than 4 MB on ia32, or 2 MB on x86_64,
> __vmalloc_area_node() has to allocate more than PAGE_SIZE bytes to store
> pointers to page structs. This means that two TLB translations are needed to
> access data.
>
> This patch tries a kmalloc() call, then only if this first attempt failed, a
> vmalloc() is performed. (Later, at vfree() time we chose kfree() or vfree()
> with a test on flags & VM_VPAGES : no change is needed)
>
> Most of the time, the first kmalloc() should be OK, so we reduce TLB usage.
But this is only TLB usage when managing (read: freeing) the vmalloc pages,
isn't it? Not when actually accessing the data.
I'd be inclined to NACK this, unless you can show an improvement somewhere:
it is suboptimal to even _try_ allocating higher order pages.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-10-09 16:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-06 11:49 [PATCH 0/3] Fix IO error reporting on fsync() Jan Kara
2006-10-06 11:55 ` [PATCH 1/3] " Jan Kara
2006-10-06 11:56 ` [PATCH 2/3] " Jan Kara
2006-10-06 11:57 ` [PATCH 3/3] " Jan Kara
2006-10-07 6:06 ` [PATCH 0/3] " Andrew Morton
2006-10-09 11:40 ` Jan Kara
2006-10-09 18:20 ` Andrew Morton
2006-10-10 11:56 ` Jan Kara
2006-10-09 14:47 ` [PATCH] Try to avoid a pessimistic vmalloc() recursion Eric Dumazet
2006-10-09 16:25 ` Nick Piggin [this message]
2006-10-09 19:43 ` Eric Dumazet
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=452A77ED.6070001@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=dada1@cosmosbay.com \
--cc=linux-kernel@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.