[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:3.110 / U:0.196 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site