Re: Patch to reorder functions in the vmlinux to a defined order

[Arjan van de Ven]

Andi Kleen wrote:
> On Thursday 23 February 2006 16:09, Arjan van de Ven wrote:
>
> > This patch puts the infrastructure in place to allow for a reordering of
> > functions based inside the vmlinux. The general idea is that it is possible
> > to put all "common" functions into the first 2Mb of the code, so that they
> > are covered by one TLB entry. This as opposed to the current situation where
> > a typical vmlinux covers about 3.5Mb (on x86-64) and thus 2 TLB entries.
> > (This patch depends on the previous patch to pin head.S as first in the order)
>
> I think you would first need to move the code first for that. Currently it starts
> at 1MB, which means 1MB is already wasted of the aligned 2MB TLB entry.
>
> I wouldn't have a problem with moving the 64bit kernel to 2MB though.

ok I am hoping that 1Mb would be enough already but I'll investigate 
this, it sure makes sense
> > I think that to get to a better list we need to invite people to submit
> > their own profiles, and somehow add those all up and base the final list on
> > that. I'm willing to do that effort if this is ends up being the prefered
> > approach. Such an effort probably needs to be repeated like once a year or
> > so to adopt to the changing nature of the kernel.
>
> Looks reasonable. 
>
> Afaik newer gcc can even separate likely and unlikely code into different sections.
> I don't see you trying to handle that. 

last discussion about this was that it made code actually bigger because 
it now needs long rather than local jumps etc, so the gcc people aren't 
too fond of it.

> Also if you're serious about saving TLBs it might be worth it to prereserve
> some memory near the main kernel mapping for modules (e.g. with a boot option) 
> and load them there. Then they would be covered with the same TLB entry too.

that's on my to-look-at list already yes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/