[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081116.001926.150424480.davem@davemloft.net>
Date: Sun, 16 Nov 2008 00:19:26 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: arjan@...radead.org
Cc: laijs@...fujitsu.com, akpm@...ux-foundation.org, menage@...gle.com,
kamezawa.hiroyu@...fujitsu.com, balbir@...ux.vnet.ibm.com,
jens.axboe@...cle.com, jack@...e.cz, jes@....com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] mm: introduce simple_malloc()/simple_free()
From: Arjan van de Ven <arjan@...radead.org>
Date: Sat, 15 Nov 2008 20:52:29 -0800
> On Sun, 16 Nov 2008 12:33:15 +0800
> Lai Jiangshan <laijs@...fujitsu.com> wrote:
>
> >
> > some subsystem needs vmalloc() when required memory is large.
> > but current kernel has not APIs for this requirement.
> > this patch introduces simple_malloc() and simple_free().
>
> I kinda really don't like this approach. vmalloc() (and especially,
> vfree()) is a really expensive operation, and vmalloc()'d memory is
> also slower (due to tlb pressure). Realistically, people should try hard
> to use small datastructure instead....
This is happening in many places, already, for good reason.
There are lots of places where we can't (core hash tables, etc.) and
we want NUMA spreading and reliable allocation, and thus vmalloc it
is.
And with Nick Piggin's recent patches cost of the vmalloc allocation
operation itself is no longer an issue.
I encouraged people to write this patch because we _ALREADY DO THIS_
in many places and it's pure code duplication.
And whatever particular heuristics you think are best for these cases,
with a common piece of code you can enforce it in ONE place instead of
several which is what is happening right now..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists