Re: [PATCH 1/7] mm: introduce simple_malloc()/simple_free()

["Dave Airlie" <airlied@gmail.com>]

On Mon, Nov 17, 2008 at 4:57 AM, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sun, 16 Nov 2008 00:19:26 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Arjan van de Ven <arjan@infradead.org>
>> Date: Sat, 15 Nov 2008 20:52:29 -0800
>>
>> > On Sun, 16 Nov 2008 12:33:15 +0800
>> > Lai Jiangshan <laijs@cn.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.
>
> vmalloc() isn't 100% evil; for truely long term stuff it's sometimes a
> quite reasonable solution.
>
> There are some issues with it still: the vmalloc() space is shared
> with ioremap, modules and others and it's not all that big on 32 bit; on
> x86 you could well end up with only 64Mb total (after taking out the
> various ioremap's etc).
>
> Yes there's places where it's then totally fine to dip into this space
> at boot/init time. You mention a few very good users.
> (There's still the tlb miss cost on use but on modern cpus a tlb miss
> is actually quite cheap)
>
> But this doesn't make vmalloc() the magic bullet that solves the "oh
> Linux can't allocate large chunks of memory" problem. Specifically in
> driver space for things that get ported from other OSes.

So we keep the duplicated code? or we just audit new callers.... I
think this patch
makes it easier to spot new callers doing something stupid. As davem
said we duplicate
this code all over the place, so for that reason along a simple
wrapper makes things a lot
easier, and also possibly a lot easier to change in the future to a
new non-sucky API.

So I'm all for it maybe with a non simple name.

Dave.

>
> --
> Arjan van de Ven        Intel Open Source Technology Centre
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>