[lkml]   [2009]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 04/20] Convert gfp_zone() to use a table of precalculated value
    On Mon, Feb 23, 2009 at 11:33:00AM -0500, Christoph Lameter wrote:
    > On Mon, 23 Feb 2009, Mel Gorman wrote:
    > > I was concerned with mispredictions here rather than the actual assembly
    > > and gfp_zone is inlined so it's lot of branches introduced in a lot of paths.
    > The amount of speculation that can be done by the processor pretty
    > limited to a few instructions. So the impact of a misprediction also
    > should be minimal.

    It really is quite a bit of code overall.

    text data bss dec hex filename
    4071245 823620 741180 5636045 55ffcd linux-2.6.29-rc5-vanilla/vmlinux
    4070872 823684 741180 5635736 55fe98 linux-2.6.29-rc5-convert-gfpzone/vmlinux

    That's 373 bytes of text with oodles of branches. I don't know what the
    cost of misprediction is going to be but surely this is having some impact
    on the branch prediction tables?

    > The decoder is likely to have sucked in the following
    > code anyways.

    Probably. To be honest, measuring this would likely be tricker but this
    is less branches and less code in a fast path. The question is if a
    cache line of data is justified or not. Right now, I think it is but
    I'll go with the general consensus if we can find one.

    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab

     \ /
      Last update: 2009-02-23 18:45    [W:0.021 / U:4.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site