lkml.org 
[lkml]   [2009]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 3/4 -mm] flex_array: poison free elements
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.



\
 
 \ /
  Last update: 2009-09-09 05:35    [W:0.091 / U:0.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site