Re: [patch 3/4 -mm] flex_array: poison free elements

[Li Zefan <lizf@cn.fujitsu.com>]

David Rientjes wrote:
> On Wed, 9 Sep 2009, Li Zefan wrote:
> 
>>> I'm struggling to find other examples.  Dave, do you know of any 
>>> subsystems in the kernel that can readily be converted to using flex 
>>> array?
>> Actually I'm planing to try to convert to use flex array in
>> kernel/trace/ftrace.c, and it needs some change in flex array,
>> and I'll have to check if it will have a performance effect
>> or not.
>>
> 
> That's cool, but it looks like none of those allocations currently would 
> ever exceed PAGE_SIZE.  The return stack for each task would be a flex 
> array of 50 elements, each element being 40 bytes for a maximum array 
> size of 2KB.  The tasklist would allocate a flex array of pointers to 
> struct ftrace_ret_stack with a maximum of 32 elements.  On x86_64, that 
> has a maximum size of 256 bytes.
> 
> So while you would be converting existing kernel code to use the new 
> interface, which is great, it doesn't have any advantage over the existing 
> implementation.  I was looking for a current use-case that would otherwise 
> use vmalloc because the entire array could not fit into a single page.
> 

I was not talking about ftrace_ret_stack, I was talking about
struct ftrace_page and struct ftrace_profile_page. ;)

Each page holds an array of records, and there is a list linking
those pages. The total nr of elements can be the nr of functions
in kernel.

I think flex array can be used here to remove duplicate
implementation.