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.023 / U:29.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site