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

[Balbir Singh <balbir@linux.vnet.ibm.com>]

Dave Airlie wrote:
> 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.

Yes, tracking vmalloc() spillage all over the place is harder than using one
abstraction and fixing that appropriately if needed (specially for 32 bit systems).

-- 
	Balbir