Messages in this thread | | | Date | Wed, 09 Sep 2009 11:31:01 +0800 | From | Li Zefan <> | Subject | Re: [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.
| |