* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
@ 2006-02-23 16:00 ` Andi Kleen
2006-02-23 16:02 ` Arjan van de Ven
2006-02-23 16:43 ` Arjan van de Ven
2006-02-23 16:48 ` Linus Torvalds
` (3 subsequent siblings)
4 siblings, 2 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 16:00 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, torvalds, akpm, mingo
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.
>
> 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.
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.
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:00 ` Andi Kleen
@ 2006-02-23 16:02 ` Arjan van de Ven
2006-02-23 16:43 ` Arjan van de Ven
1 sibling, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 16:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, torvalds, akpm, mingo
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
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:00 ` Andi Kleen
2006-02-23 16:02 ` Arjan van de Ven
@ 2006-02-23 16:43 ` Arjan van de Ven
2006-02-23 16:48 ` Andi Kleen
2006-02-23 17:08 ` Linus Torvalds
1 sibling, 2 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 16:43 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, torvalds, akpm, mingo
On Thu, 2006-02-23 at 17:00 +0100, 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.
that was easy since it's a Config entry already ;)
---
As suggested by Andi (and Alan), move the default kernel location
from 1Mb to 2Mb, to align to the start of a TLB entry.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
arch/x86_64/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-reorder/arch/x86_64/Kconfig
===================================================================
--- linux-2.6.16-reorder.orig/arch/x86_64/Kconfig
+++ linux-2.6.16-reorder/arch/x86_64/Kconfig
@@ -444,10 +444,10 @@ config CRASH_DUMP
config PHYSICAL_START
hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
default "0x1000000" if CRASH_DUMP
- default "0x100000"
+ default "0x200000"
help
This gives the physical address where the kernel is loaded. Normally
- for regular kernels this value is 0x100000 (1MB). But in the case
+ for regular kernels this value is 0x200000 (2MB). But in the case
of kexec on panic the fail safe kernel needs to run at a different
address than the panic-ed kernel. This option is used to set the load
address for kernels used to capture crash dump on being kexec'ed
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:43 ` Arjan van de Ven
@ 2006-02-23 16:48 ` Andi Kleen
2006-02-23 16:49 ` Arjan van de Ven
2006-02-23 17:08 ` Linus Torvalds
1 sibling, 1 reply; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 16:48 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, torvalds, akpm, mingo
On Thursday 23 February 2006 17:43, Arjan van de Ven wrote:
> On Thu, 2006-02-23 at 17:00 +0100, 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.
>
> that was easy since it's a Config entry already ;)
I assume you boot tested it?
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:48 ` Andi Kleen
@ 2006-02-23 16:49 ` Arjan van de Ven
0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 16:49 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel, torvalds, akpm, mingo
Andi Kleen wrote:
> On Thursday 23 February 2006 17:43, Arjan van de Ven wrote:
>> On Thu, 2006-02-23 at 17:00 +0100, 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.
>> that was easy since it's a Config entry already ;)
>
>
> I assume you boot tested it?
yes it booted on my testbox, and system.map showed the 2 instead of the 1
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:43 ` Arjan van de Ven
2006-02-23 16:48 ` Andi Kleen
@ 2006-02-23 17:08 ` Linus Torvalds
2006-02-23 17:20 ` Andi Kleen
` (3 more replies)
1 sibling, 4 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 17:08 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Andi Kleen, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, Arjan van de Ven wrote:
> >
> > 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.
>
> that was easy since it's a Config entry already ;)
Btw, the "low TLB entry" for the direct-mapped case can't be used as a
hugetlb page anyway, due to the MMU splitting it up due to the special
MTRR regions, if I recall correctly.
So this is probably a bigger performance win than just the difference
between using one or two TLB entries.
The same should be true on x86, btw. Where we should use a physical start
address of 4MB for best performance.
Does anybody want to run benchmarks? (Totally untested, may not boot,
might physically accost your pets for all I know).
Linus
---
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 0afec85..d2b1df8 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -715,7 +715,7 @@ config PHYSICAL_START
hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
default "0x1000000" if CRASH_DUMP
- default "0x100000"
+ default "0x400000"
help
This gives the physical address where the kernel is loaded. Normally
for regular kernels this value is 0x100000 (1MB). But in the case
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:08 ` Linus Torvalds
@ 2006-02-23 17:20 ` Andi Kleen
2006-02-23 17:34 ` Alan Cox
2006-02-23 17:44 ` Linus Torvalds
2006-02-23 19:03 ` linux-os (Dick Johnson)
` (2 subsequent siblings)
3 siblings, 2 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, linux-kernel, akpm, mingo
On Thursday 23 February 2006 18:08, Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
> > >
> > > 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.
> >
> > that was easy since it's a Config entry already ;)
>
> Btw, the "low TLB entry" for the direct-mapped case can't be used as a
> hugetlb page anyway, due to the MMU splitting it up due to the special
> MTRR regions, if I recall correctly.
I was to suggest the same thing originally, but on several boxes I checked
there weren't any special MTRRs < 1MB, only in the PCI memory hole
<4GB. I suspect there isn't just any interesting hardware in 640K anymore.
BTW I have been also pondering some time to really trust e820 and not
forcibly reserve 640K-1MB on 64bit. That code was inherited from i386,
but probably never made too much sense
[I remember actually taking it out very early, but then putting
it back when I was hunting some insidious unrelated bug. But it wasn't that]
Perhaps that would be a good idea to ignore that newer i386 systems too
(newer defined as having DMI BIOS dates >2000 or so)
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:20 ` Andi Kleen
@ 2006-02-23 17:34 ` Alan Cox
2006-02-23 18:13 ` Andi Kleen
2006-02-23 17:44 ` Linus Torvalds
1 sibling, 1 reply; 60+ messages in thread
From: Alan Cox @ 2006-02-23 17:34 UTC (permalink / raw)
To: Andi Kleen; +Cc: Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo
On Iau, 2006-02-23 at 18:20 +0100, Andi Kleen wrote:
> BTW I have been also pondering some time to really trust e820 and not
> forcibly reserve 640K-1MB on 64bit. That code was inherited from i386,
> but probably never made too much sense
Depends if you want your boot video stuff to work, and vga space, and
also how the ISA hole is used, some chipsets seem to use the RAM that
would be there remapped elsewhere as SMM ram.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:34 ` Alan Cox
@ 2006-02-23 18:13 ` Andi Kleen
0 siblings, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 18:13 UTC (permalink / raw)
To: Alan Cox; +Cc: Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo
On Thursday 23 February 2006 18:34, Alan Cox wrote:
> On Iau, 2006-02-23 at 18:20 +0100, Andi Kleen wrote:
> > BTW I have been also pondering some time to really trust e820 and not
> > forcibly reserve 640K-1MB on 64bit. That code was inherited from i386,
> > but probably never made too much sense
>
> Depends if you want your boot video stuff to work, and vga space, and
> also how the ISA hole is used, some chipsets seem to use the RAM that
> would be there remapped elsewhere as SMM ram.
e820 should report that.
I would hope that e820 is correct on modern systems.
Ok it would be a test - if it causes too much collational damage it could be undone.
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:20 ` Andi Kleen
2006-02-23 17:34 ` Alan Cox
@ 2006-02-23 17:44 ` Linus Torvalds
2006-02-23 18:14 ` Andi Kleen
1 sibling, 1 reply; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 17:44 UTC (permalink / raw)
To: Andi Kleen; +Cc: Arjan van de Ven, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, Andi Kleen wrote:
>
> I was to suggest the same thing originally, but on several boxes I checked
> there weren't any special MTRRs < 1MB, only in the PCI memory hole
> <4GB. I suspect there isn't just any interesting hardware in 640K anymore.
I wasn't talking about the regular MTRR's, but about the magic one: the
"Fixed Range MTRRs" that only map the low 1MB.
I'm pretty sure that they are still used by the BIOS to set up the
640k->1M window.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:44 ` Linus Torvalds
@ 2006-02-23 18:14 ` Andi Kleen
0 siblings, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 18:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, linux-kernel, akpm, mingo
On Thursday 23 February 2006 18:44, Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Andi Kleen wrote:
> >
> > I was to suggest the same thing originally, but on several boxes I checked
> > there weren't any special MTRRs < 1MB, only in the PCI memory hole
> > <4GB. I suspect there isn't just any interesting hardware in 640K anymore.
>
> I wasn't talking about the regular MTRR's, but about the magic one: the
> "Fixed Range MTRRs" that only map the low 1MB.
>
> I'm pretty sure that they are still used by the BIOS to set up the
> 640k->1M window.
Ah you're right i forgot that one.
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:08 ` Linus Torvalds
2006-02-23 17:20 ` Andi Kleen
@ 2006-02-23 19:03 ` linux-os (Dick Johnson)
2006-02-23 19:32 ` Linus Torvalds
2006-02-23 19:23 ` Rene Herman
2006-02-23 20:07 ` Andy Whitcroft
3 siblings, 1 reply; 60+ messages in thread
From: linux-os (Dick Johnson) @ 2006-02-23 19:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, Linus Torvalds wrote:
>
>
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>>>
>>> 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.
>>
>> that was easy since it's a Config entry already ;)
>
> Btw, the "low TLB entry" for the direct-mapped case can't be used as a
> hugetlb page anyway, due to the MMU splitting it up due to the special
> MTRR regions, if I recall correctly.
>
> So this is probably a bigger performance win than just the difference
> between using one or two TLB entries.
>
> The same should be true on x86, btw. Where we should use a physical start
> address of 4MB for best performance.
>
> Does anybody want to run benchmarks? (Totally untested, may not boot,
> might physically accost your pets for all I know).
>
> Linus
I just reconfigured and rebuilt linux-2.6.15.4 to put PHYSICAL_START
at 0x00400000, unconditionally and it booted fine and is working so
a 'boot' shouldn't be a problem.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:03 ` linux-os (Dick Johnson)
@ 2006-02-23 19:32 ` Linus Torvalds
2006-02-24 12:43 ` linux-os (Dick Johnson)
0 siblings, 1 reply; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 19:32 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, linux-os (Dick Johnson) wrote:
> >
> > Does anybody want to run benchmarks? (Totally untested, may not boot,
> > might physically accost your pets for all I know).
> >
> > Linus
>
> I just reconfigured and rebuilt linux-2.6.15.4 to put PHYSICAL_START
> at 0x00400000, unconditionally and it booted fine and is working so
> a 'boot' shouldn't be a problem.
I ended up doing even more.
For me, running lmbench with this, it seems to improve some things by up
to 20% (pipe bandwidth and latency, small file delete), some other things
by 10% (larger file delete), and others not at all.
Still, that 20% is _huge_.
HOWEVER. I didn't compare very strictly. I should have done many more runs
(I only did three), and more importantly, I should have compared the exact
same kernel (I compared the new results against a kernel that was a couple
of weeks old, so there were other differences). So it's a bit suspect.
Finally, it might depend on the core a lot, and other cores might not get
the same results.
So somebody should do a much better test. I'm too lazy.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:32 ` Linus Torvalds
@ 2006-02-24 12:43 ` linux-os (Dick Johnson)
0 siblings, 0 replies; 60+ messages in thread
From: linux-os (Dick Johnson) @ 2006-02-24 12:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, linux-os (Dick Johnson) wrote:
>>>
>>> Does anybody want to run benchmarks? (Totally untested, may not boot,
>>> might physically accost your pets for all I know).
>>>
>>> Linus
>>
>> I just reconfigured and rebuilt linux-2.6.15.4 to put PHYSICAL_START
>> at 0x00400000, unconditionally and it booted fine and is working so
>> a 'boot' shouldn't be a problem.
>
> I ended up doing even more.
>
> For me, running lmbench with this, it seems to improve some things by up
> to 20% (pipe bandwidth and latency, small file delete), some other things
> by 10% (larger file delete), and others not at all.
>
> Still, that 20% is _huge_.
>
> HOWEVER. I didn't compare very strictly. I should have done many more runs
> (I only did three), and more importantly, I should have compared the exact
> same kernel (I compared the new results against a kernel that was a couple
> of weeks old, so there were other differences). So it's a bit suspect.
> Finally, it might depend on the core a lot, and other cores might not get
> the same results.
>
> So somebody should do a much better test. I'm too lazy.
>
> Linus
>
I compiled the kernel with the kernel start address at both
0x00400000 and 0x00100000.
Conditions:
No network attached, machine newly rebooted, no other activity.
Meminfo AFTER the last compile.
MemTotal: 773856 kB
MemFree: 16388 kB
Buffers: 328532 kB
Cached: 39888 kB
SwapCached: 0 kB
Active: 129072 kB
Inactive: 258928 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 773856 kB
LowFree: 16388 kB
SwapTotal: 907664 kB
SwapFree: 907664 kB
Dirty: 4 kB
Writeback: 0 kB
Mapped: 33924 kB
Slab: 361224 kB
CommitLimit: 1294592 kB
Committed_AS: 29292 kB
PageTables: 736 kB
VmallocTotal: 253652 kB
VmallocUsed: 2708 kB
VmallocChunk: 250684 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 4096 kB
CPU Info:
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping : 7
cpu MHz : 2793.305
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips : 5589.53
This CPU is supposed to be SMP, and the kernel is compiled SMP, but
I was never able to have the two cores show up. It shouldn't affect
the comparison bench-marks.
Tail end of the log with the start at 0x00400000.
CC sound/usb/snd-usb-audio.mod.o
LD [M] sound/usb/snd-usb-audio.ko
CC sound/usb/snd-usb-lib.mod.o
LD [M] sound/usb/snd-usb-lib.ko
CC sound/usb/usx2y/snd-usb-usx2y.mod.o
LD [M] sound/usb/usx2y/snd-usb-usx2y.ko
real 33m4.832s
user 29m47.359s
sys 3m13.611s
Tail end of the log with the start at 0x00100000.
CC sound/usb/snd-usb-audio.mod.o
LD [M] sound/usb/snd-usb-audio.ko
CC sound/usb/snd-usb-lib.mod.o
LD [M] sound/usb/snd-usb-lib.ko
CC sound/usb/usx2y/snd-usb-usx2y.mod.o
LD [M] sound/usb/usx2y/snd-usb-usx2y.ko
real 33m21.078s
user 29m41.274s
sys 3m13.910s
Conclusion: It doesn't make a damn bit of difference one way or
the other on this machine!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:08 ` Linus Torvalds
2006-02-23 17:20 ` Andi Kleen
2006-02-23 19:03 ` linux-os (Dick Johnson)
@ 2006-02-23 19:23 ` Rene Herman
2006-02-23 19:31 ` Andi Kleen
` (2 more replies)
2006-02-23 20:07 ` Andy Whitcroft
3 siblings, 3 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 19:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
Linus Torvalds wrote:
> The same should be true on x86, btw. Where we should use a physical start
> address of 4MB for best performance.
Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
not many people are really using that anyway anymore these days, but if
no downsides maybe?
Also, did the kernel still boot on a 4M machine, and would it still do
so with the change to 4M as posted? 2.4 used to boot fine with 4M. Not
certain anymore if I ever tested that with 2.6 (and can't right now).
Rene.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:23 ` Rene Herman
@ 2006-02-23 19:31 ` Andi Kleen
2006-02-23 19:34 ` Alan Cox
2006-02-23 19:35 ` Linus Torvalds
2 siblings, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-23 19:31 UTC (permalink / raw)
To: Rene Herman; +Cc: Linus Torvalds, Arjan van de Ven, linux-kernel, akpm, mingo
On Thursday 23 February 2006 20:23, Rene Herman wrote:
> Linus Torvalds wrote:
>
> > The same should be true on x86, btw. Where we should use a physical start
> > address of 4MB for best performance.
>
> Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
> not many people are really using that anyway anymore these days, but if
> no downsides maybe?
That would prevent booting on < 18MB or so
>
> Also, did the kernel still boot on a 4M machine, and would it still do
> so with the change to 4M as posted? 2.4 used to boot fine with 4M. Not
> certain anymore if I ever tested that with 2.6 (and can't right now).
It wouldn't without additional changes.
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:23 ` Rene Herman
2006-02-23 19:31 ` Andi Kleen
@ 2006-02-23 19:34 ` Alan Cox
2006-02-23 19:48 ` Rene Herman
2006-02-23 19:35 ` Linus Torvalds
2 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2006-02-23 19:34 UTC (permalink / raw)
To: Rene Herman
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
On Iau, 2006-02-23 at 20:23 +0100, Rene Herman wrote:
> Linus Torvalds wrote:
>
> > The same should be true on x86, btw. Where we should use a physical start
> > address of 4MB for best performance.
>
> Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
> not many people are really using that anyway anymore these days, but if
> no downsides maybe?
Certainly the PAE kernel might as well do that and the AMD64 if it
doesn't already. There are complications however getting above 16MB
because 16bit protected mode (and maybe the BIOS helpers - I need to
check that) can't hit it.
We also used to have people DMAing into static kernel buffers in older
days but hopefully that habit is now dead and gone because modules
sorted most of it out.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:34 ` Alan Cox
@ 2006-02-23 19:48 ` Rene Herman
0 siblings, 0 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 19:48 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Alan Cox wrote:
> On Iau, 2006-02-23 at 20:23 +0100, Rene Herman wrote:
>> Does 16MB still work? Gets the kernel out of the old ZONE_DMA. I suppose
>> not many people are really using that anyway anymore these days, but if
>> no downsides maybe?
>
> Certainly the PAE kernel might as well do that and the AMD64 if it
> doesn't already. There are complications however getting above 16MB
> because 16bit protected mode (and maybe the BIOS helpers - I need to
> check that) can't hit it.
INT 15/AH=0x87 (move from low to high) on a 386+ should work, according
to the documentation I have... Is PM16 used anywhere?
> We also used to have people DMAing into static kernel buffers in older
> days but hopefully that habit is now dead and gone because modules
> sorted most of it out.
Good method to flush out any possible remaining users :-)
Rene.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:23 ` Rene Herman
2006-02-23 19:31 ` Andi Kleen
2006-02-23 19:34 ` Alan Cox
@ 2006-02-23 19:35 ` Linus Torvalds
2006-02-23 19:44 ` Arjan van de Ven
` (2 more replies)
2 siblings, 3 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 19:35 UTC (permalink / raw)
To: Rene Herman; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, Rene Herman wrote:
>
> Also, did the kernel still boot on a 4M machine, and would it still do so with
> the change to 4M as posted? 2.4 used to boot fine with 4M. Not certain anymore
> if I ever tested that with 2.6 (and can't right now).
If you want to boot a 4MB machine with the suggested patch, you'd have to
enable CONFIG_EMBEDDED (something you'd likely want to do anyway, for a 4M
machine), and turn the physical start address back down to 1MB.
That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
embedded these days (you'd want to enable EMBEDDED just to turn off some
other things that make the kernel bigger), but I can imagine that real
people run Linux/x86 in 16MB as long as they don't run X.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:35 ` Linus Torvalds
@ 2006-02-23 19:44 ` Arjan van de Ven
2006-02-23 20:13 ` Rene Herman
2006-02-24 1:38 ` Martin Bligh
2 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Rene Herman, Andi Kleen, linux-kernel, akpm, mingo
\
> That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
> embedded these days (you'd want to enable EMBEDDED just to turn off some
> other things that make the kernel bigger), but I can imagine that real
> people run Linux/x86 in 16MB as long as they don't run X.
for PAE it might make sense to just bump it to 16... but then again..
DMA zone pressure in 2.6 is almost gone anyway
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:35 ` Linus Torvalds
2006-02-23 19:44 ` Arjan van de Ven
@ 2006-02-23 20:13 ` Rene Herman
2006-02-23 20:26 ` Dave Jones
2006-02-23 23:19 ` Linus Torvalds
2006-02-24 1:38 ` Martin Bligh
2 siblings, 2 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 20:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
Linus Torvalds wrote:
> If you want to boot a 4MB machine with the suggested patch, you'd
> have to enable CONFIG_EMBEDDED (something you'd likely want to do
> anyway, for 4M machine), and turn the physical start address back
> down to 1MB.
Okay. I suppose the only other option is to make "physical_start" a
variable passed in by the bootloader so that it could make a runtime
decision? Ie, place us at min(top_of_mem, 4G) if it cared to. I just
grepped for PHYSICAL_START and this didn't look _too_ bad.
I'm out of my league here though -- if I remember correctly from some
reading of the early bootcode I once did, the kernel set up some
temporary tables first to only cover the first few MB? If so, then I
guess it would be a significant change.
Seems a bit cleaner though than just hardcoding the address.
> That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
> embedded these days (you'd want to enable EMBEDDED just to turn off
> some other things that make the kernel bigger), but I can imagine
> that real people run Linux/x86 in 16MB as long as they don't run X.
My 386 is happy with its current 16M (it can't cache all of the 32M I
can physically put in), used to be happy with 8M, and used to boot with
4M... ofcourse, although it's not very embedded (you should see it) it's
also not very "real" in that sense ;-)
Love the machine to death, though...
Rene.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 20:13 ` Rene Herman
@ 2006-02-23 20:26 ` Dave Jones
2006-02-24 2:44 ` Fernando Luis Vazquez Cao
2006-02-23 23:19 ` Linus Torvalds
1 sibling, 1 reply; 60+ messages in thread
From: Dave Jones @ 2006-02-23 20:26 UTC (permalink / raw)
To: Rene Herman
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
On Thu, Feb 23, 2006 at 09:13:24PM +0100, Rene Herman wrote:
> Linus Torvalds wrote:
>
> >If you want to boot a 4MB machine with the suggested patch, you'd
> >have to enable CONFIG_EMBEDDED (something you'd likely want to do
> >anyway, for 4M machine), and turn the physical start address back
> >down to 1MB.
>
> Okay. I suppose the only other option is to make "physical_start" a
> variable passed in by the bootloader so that it could make a runtime
> decision? Ie, place us at min(top_of_mem, 4G) if it cared to. I just
> grepped for PHYSICAL_START and this didn't look _too_ bad.
>
> I'm out of my league here though -- if I remember correctly from some
> reading of the early bootcode I once did, the kernel set up some
> temporary tables first to only cover the first few MB? If so, then I
> guess it would be a significant change.
>
> Seems a bit cleaner though than just hardcoding the address.
the kdump people were looking at making the kernel runtime relocatable
at one point, which with my distro-vendor hat on, would be useful
as it'd mean we could use the same kernel image for normal boot, and
also for the 'kdump kernel' (Right now, we ship another set of
kernels for each arch with a different PHYSICAL_START).
(You wouldn't believe how much grief we get from the installer folks
for adding another set of kernel images to the ISOs).
I think that work stalled a while back though.
Dave
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 20:26 ` Dave Jones
@ 2006-02-24 2:44 ` Fernando Luis Vazquez Cao
2006-02-24 2:47 ` Andi Kleen
2006-02-24 14:44 ` Theodore Ts'o
0 siblings, 2 replies; 60+ messages in thread
From: Fernando Luis Vazquez Cao @ 2006-02-24 2:44 UTC (permalink / raw)
To: Dave Jones
Cc: Rene Herman, Linus Torvalds, Arjan van de Ven, Andi Kleen,
linux-kernel, akpm, mingo
On Thu, 2006-02-23 at 15:26 -0500, Dave Jones wrote:
> On Thu, Feb 23, 2006 at 09:13:24PM +0100, Rene Herman wrote:
> > Linus Torvalds wrote:
> >
> > >If you want to boot a 4MB machine with the suggested patch, you'd
> > >have to enable CONFIG_EMBEDDED (something you'd likely want to do
> > >anyway, for 4M machine), and turn the physical start address back
> > >down to 1MB.
> >
> > Okay. I suppose the only other option is to make "physical_start" a
> > variable passed in by the bootloader so that it could make a runtime
> > decision? Ie, place us at min(top_of_mem, 4G) if it cared to. I just
> > grepped for PHYSICAL_START and this didn't look _too_ bad.
> >
> > I'm out of my league here though -- if I remember correctly from some
> > reading of the early bootcode I once did, the kernel set up some
> > temporary tables first to only cover the first few MB? If so, then I
> > guess it would be a significant change.
> >
> > Seems a bit cleaner though than just hardcoding the address.
>
> the kdump people were looking at making the kernel runtime relocatable
> at one point, which with my distro-vendor hat on, would be useful
> as it'd mean we could use the same kernel image for normal boot, and
> also for the 'kdump kernel'
The mkdump team has accomplished this ...
> (Right now, we ship another set of
> kernels for each arch with a different PHYSICAL_START).
... so that we do not need to hard-code PHYSICAL_START. The dump capture
kernel is able to run from any memory address the host kernel reserves
for it. The are some limitations though:
- i386: the second kernel has to be loaded in low memory
- x86_64: the second kernel has to be loaded below 1GB (we are working
to move this limit to 4GB)
> (You wouldn't believe how much grief we get from the installer folks
> for adding another set of kernel images to the ISOs).
>
> I think that work stalled a while back though.
The mkdump team has been using runtime relocatable kernels for two years
and we are currently working on porting this functionality to kdump. I
was wondering if it would be accepted mainstream.
Regards,
Fernando
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 2:44 ` Fernando Luis Vazquez Cao
@ 2006-02-24 2:47 ` Andi Kleen
2006-02-24 14:44 ` Theodore Ts'o
1 sibling, 0 replies; 60+ messages in thread
From: Andi Kleen @ 2006-02-24 2:47 UTC (permalink / raw)
To: Fernando Luis Vazquez Cao
Cc: Dave Jones, Rene Herman, Linus Torvalds, Arjan van de Ven,
linux-kernel, akpm, mingo
On Friday 24 February 2006 03:44, Fernando Luis Vazquez Cao wrote:
> The mkdump team has been using runtime relocatable kernels for two years
> and we are currently working on porting this functionality to kdump. I
> was wondering if it would be accepted mainstream.
The question cannot be answered without a patch to look at. Just post
it once it works.
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 2:44 ` Fernando Luis Vazquez Cao
2006-02-24 2:47 ` Andi Kleen
@ 2006-02-24 14:44 ` Theodore Ts'o
1 sibling, 0 replies; 60+ messages in thread
From: Theodore Ts'o @ 2006-02-24 14:44 UTC (permalink / raw)
To: Fernando Luis Vazquez Cao
Cc: Dave Jones, Rene Herman, Linus Torvalds, Arjan van de Ven,
Andi Kleen, linux-kernel, akpm, mingo
On Fri, Feb 24, 2006 at 11:44:15AM +0900, Fernando Luis Vazquez Cao wrote:
>
> The mkdump team has been using runtime relocatable kernels for two years
> and we are currently working on porting this functionality to kdump. I
> was wondering if it would be accepted mainstream.
What's the overhead? (In code size, complexity, performance, etc.?)
- Ted
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 20:13 ` Rene Herman
2006-02-23 20:26 ` Dave Jones
@ 2006-02-23 23:19 ` Linus Torvalds
2006-02-23 23:53 ` Rene Herman
2006-02-24 14:11 ` Eric W. Biederman
1 sibling, 2 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 23:19 UTC (permalink / raw)
To: Rene Herman; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
On Thu, 23 Feb 2006, Rene Herman wrote:
>
> Okay. I suppose the only other option is to make "physical_start" a variable
> passed in by the bootloader so that it could make a runtime decision? Ie,
> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
> PHYSICAL_START and this didn't look _too_ bad.
No can do. You'd have to make the kernel relocatable, and do load-time
fixups. Very invasive.
It's certainly _possible_, but it's a whole new stage in the boot, one
that we've never done before.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 23:19 ` Linus Torvalds
@ 2006-02-23 23:53 ` Rene Herman
2006-02-24 14:23 ` Eric W. Biederman
2006-02-24 14:23 ` Eric W. Biederman
2006-02-24 14:11 ` Eric W. Biederman
1 sibling, 2 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-23 23:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
Linus Torvalds wrote:
> On Thu, 23 Feb 2006, Rene Herman wrote:
>> Okay. I suppose the only other option is to make "physical_start" a variable
>> passed in by the bootloader so that it could make a runtime decision? Ie,
>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>> PHYSICAL_START and this didn't look _too_ bad.
>
> No can do. You'd have to make the kernel relocatable, and do load-time
> fixups. Very invasive.
Yes, that wasn't too smart. I believe in principe most of it _could_ be
done via some pagetable trickery though, with the kernel still at a
fixed virtual address?
Rene.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 23:53 ` Rene Herman
@ 2006-02-24 14:23 ` Eric W. Biederman
2006-02-24 14:23 ` Eric W. Biederman
1 sibling, 0 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:23 UTC (permalink / raw)
To: Rene Herman
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Rene Herman <rene.herman@keyaccess.nl> writes:
> Linus Torvalds wrote:
>
>> On Thu, 23 Feb 2006, Rene Herman wrote:
>
>>> Okay. I suppose the only other option is to make "physical_start" a variable
>>> passed in by the bootloader so that it could make a runtime decision? Ie,
>>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>>> PHYSICAL_START and this didn't look _too_ bad.
>> No can do. You'd have to make the kernel relocatable, and do load-time
>> fixups. Very invasive.
>
> Yes, that wasn't too smart. I believe in principe most of it _could_ be done via
> some pagetable trickery though, with the kernel still at a fixed virtual
> address?
The page table trickery is actually the more invasive approach. I believe
for 32 bit kernels the real problem is giving up the identity mapping of
low memory. Short of the moving the kernel to end of the address space
where vmalloc and the fixmaps are now I don't think there is a reasonable chunk
of the address space we can use.
Eric
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 23:53 ` Rene Herman
2006-02-24 14:23 ` Eric W. Biederman
@ 2006-02-24 14:23 ` Eric W. Biederman
2006-02-24 15:30 ` Rene Herman
1 sibling, 1 reply; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:23 UTC (permalink / raw)
To: Rene Herman
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Rene Herman <rene.herman@keyaccess.nl> writes:
> Linus Torvalds wrote:
>
>> On Thu, 23 Feb 2006, Rene Herman wrote:
>
>>> Okay. I suppose the only other option is to make "physical_start" a variable
>>> passed in by the bootloader so that it could make a runtime decision? Ie,
>>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>>> PHYSICAL_START and this didn't look _too_ bad.
>> No can do. You'd have to make the kernel relocatable, and do load-time
>> fixups. Very invasive.
>
> Yes, that wasn't too smart. I believe in principe most of it _could_ be done via
> some pagetable trickery though, with the kernel still at a fixed virtual
> address?
The page table trickery is actually the more invasive approach. I believe
for 32 bit kernels the real problem is giving up the identity mapping of
low memory. Short of the moving the kernel to end of the address space
where vmalloc and the fixmaps are now I don't think there is a reasonable chunk
of the address space we can use.
Eric
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 14:23 ` Eric W. Biederman
@ 2006-02-24 15:30 ` Rene Herman
2006-02-24 15:55 ` Eric W. Biederman
0 siblings, 1 reply; 60+ messages in thread
From: Rene Herman @ 2006-02-24 15:30 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Eric W. Biederman wrote:
> The page table trickery is actually the more invasive approach. I
> believe for 32 bit kernels the real problem is giving up the identity
> mapping of low memory.
Yes, you probably don't want to have to specialcase anything there.
> Short of the moving the kernel to end of the address space where
> vmalloc and the fixmaps are now I don't think there is a reasonable
> chunk of the address space we can use.
To my handwaving ears end of the address space sounds very good though.
Is there currently any pressure on VMALLOC_RESERVE (128M)? Teaching the
linker appears to be a matter of changing __KERNEL_START. That leaves
actually mapping ourselves there, and... more invasiveness?
I saw you say you already have some actual relocating patches though?
Rene.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 15:30 ` Rene Herman
@ 2006-02-24 15:55 ` Eric W. Biederman
2006-02-24 16:48 ` Andi Kleen
2006-02-24 17:26 ` Linus Torvalds
0 siblings, 2 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 15:55 UTC (permalink / raw)
To: Rene Herman
Cc: Linus Torvalds, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Rene Herman <rene.herman@keyaccess.nl> writes:
> Eric W. Biederman wrote:
>
>> The page table trickery is actually the more invasive approach. I
>> believe for 32 bit kernels the real problem is giving up the identity
>> mapping of low memory.
>
> Yes, you probably don't want to have to specialcase anything there.
>
>> Short of the moving the kernel to end of the address space where
>> vmalloc and the fixmaps are now I don't think there is a reasonable
>> chunk of the address space we can use.
>
> To my handwaving ears end of the address space sounds very good though. Is there
> currently any pressure on VMALLOC_RESERVE (128M)? Teaching the linker appears to
> be a matter of changing __KERNEL_START. That leaves actually mapping ourselves
> there, and... more invasiveness?
__pa stops working on kernel addresses.
> I saw you say you already have some actual relocating patches though?
Yes. Will post them later today, after I get them rebased against a recent
kernel.
Eric
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 15:55 ` Eric W. Biederman
@ 2006-02-24 16:48 ` Andi Kleen
2006-02-24 20:38 ` Eric W. Biederman
2006-02-24 17:26 ` Linus Torvalds
1 sibling, 1 reply; 60+ messages in thread
From: Andi Kleen @ 2006-02-24 16:48 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Rene Herman, Linus Torvalds, Arjan van de Ven, linux-kernel, akpm,
mingo
On Friday 24 February 2006 16:55, Eric W. Biederman wrote:
> there, and... more invasiveness?
>
> __pa stops working on kernel addresses.
x86-64 always had this problem and it's not very hard to handle with a simple ?:
-Andi
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 16:48 ` Andi Kleen
@ 2006-02-24 20:38 ` Eric W. Biederman
2006-02-25 2:11 ` Folkert van Heusden
0 siblings, 1 reply; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 20:38 UTC (permalink / raw)
To: Andi Kleen
Cc: Rene Herman, Linus Torvalds, Arjan van de Ven, linux-kernel, akpm,
mingo
Andi Kleen <ak@suse.de> writes:
> On Friday 24 February 2006 16:55, Eric W. Biederman wrote:
>> there, and... more invasiveness?
>>
>> __pa stops working on kernel addresses.
>
> x86-64 always had this problem and it's not very hard to handle with a simple ?:
It has been several months but yes most of the pieces are simple.
Although you do loose the opportunities for several micro-optimizations,
that way. The point was simply that working with relocations is even
less intrusive. The changes stop at kernel/head.S if they even get
that far. Plus the proof that you have not pessimized things is
trivial, because nothing has changed.
The fact that your kernel virtual addresses can be at different
2MB/4MB aligned boundaries is a downside, as is the fact that your
bzImage becomes 5-10% larger because of all of the relocations.
Eric
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 15:55 ` Eric W. Biederman
2006-02-24 16:48 ` Andi Kleen
@ 2006-02-24 17:26 ` Linus Torvalds
2006-02-24 17:57 ` Rene Herman
1 sibling, 1 reply; 60+ messages in thread
From: Linus Torvalds @ 2006-02-24 17:26 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Rene Herman, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
On Fri, 24 Feb 2006, Eric W. Biederman wrote:
>
> > To my handwaving ears end of the address space sounds very good though. Is there
> > currently any pressure on VMALLOC_RESERVE (128M)? Teaching the linker appears to
> > be a matter of changing __KERNEL_START. That leaves actually mapping ourselves
> > there, and... more invasiveness?
>
> __pa stops working on kernel addresses.
That's not the issue.
The real issue is the _physical_ address. Nothing else matters.
If the TLB splitting on the fixed MTRRs is an issue, it depends entirely
on what physical address the kernel resides in, and the virtual address is
totally inconsequential.
So playing games with virtual mapping has absolutely no upsides, and it
definitely has downsides.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 17:26 ` Linus Torvalds
@ 2006-02-24 17:57 ` Rene Herman
2006-02-24 18:11 ` Linus Torvalds
2006-03-07 23:36 ` H. Peter Anvin
0 siblings, 2 replies; 60+ messages in thread
From: Rene Herman @ 2006-02-24 17:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric W. Biederman, Arjan van de Ven, Andi Kleen, linux-kernel,
akpm, mingo
Linus Torvalds wrote:
> The real issue is the _physical_ address. Nothing else matters.
>
> If the TLB splitting on the fixed MTRRs is an issue, it depends entirely
> on what physical address the kernel resides in, and the virtual address is
> totally inconsequential.
>
> So playing games with virtual mapping has absolutely no upsides, and it
> definitely has downsides.
The notion was that having a fixed virtual mapping of the kernel would
allow it to be loaded anywhere physically without needing to do actual
address fixups. The bootloader could then for example at runtime decide
to load the kernel at 16MB if the machine had enough memory available,
to free up ZONE_DMA. Or not do that if running on a <= 16MB machine.
Or the kdump "host" kernel would make that decission, as it seems the
want is shared with them. Eric Biederman said that fixups aren't that
bad though...
Rene.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 17:57 ` Rene Herman
@ 2006-02-24 18:11 ` Linus Torvalds
2006-03-07 23:36 ` H. Peter Anvin
1 sibling, 0 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-24 18:11 UTC (permalink / raw)
To: Rene Herman
Cc: Eric W. Biederman, Arjan van de Ven, Andi Kleen, linux-kernel,
akpm, mingo
On Fri, 24 Feb 2006, Rene Herman wrote:
>
> The notion was that having a fixed virtual mapping of the kernel would allow
> it to be loaded anywhere physically without needing to do actual address
> fixups.
Even that doesn't much help. You'd still need to fix up the actual
addresses.
Why? The virtual remapping is limited to 4MB chunks in order to be able to
remap using large pages (2MB in PAE mode). At which point there is no
advantage: you might as well just hardcode the default address to 4MB like
my trivial one-liner did (with an option for EMBEDDED people to link it
lower).
So if the point is that we want to use the same binary for both machines
with less than 4M and for bigger machines, you can't remap the kernel,
unless you start using individual pages, at which point you've destroyed
the biggest reason for doing this in the first place - since your TLB
behaviour will suck.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 17:57 ` Rene Herman
2006-02-24 18:11 ` Linus Torvalds
@ 2006-03-07 23:36 ` H. Peter Anvin
1 sibling, 0 replies; 60+ messages in thread
From: H. Peter Anvin @ 2006-03-07 23:36 UTC (permalink / raw)
To: linux-kernel
Followup to: <43FF48F2.70508@keyaccess.nl>
By author: Rene Herman <rene.herman@keyaccess.nl>
In newsgroup: linux.dev.kernel
>
> Linus Torvalds wrote:
>
> > The real issue is the _physical_ address. Nothing else matters.
> >
> > If the TLB splitting on the fixed MTRRs is an issue, it depends entirely
> > on what physical address the kernel resides in, and the virtual address is
> > totally inconsequential.
> >
> > So playing games with virtual mapping has absolutely no upsides, and it
> > definitely has downsides.
>
> The notion was that having a fixed virtual mapping of the kernel would
> allow it to be loaded anywhere physically without needing to do actual
> address fixups. The bootloader could then for example at runtime decide
> to load the kernel at 16MB if the machine had enough memory available,
> to free up ZONE_DMA. Or not do that if running on a <= 16MB machine.
>
The only machines on which ZONE_DMA matters (machines with ISA DMA
devices) are also the ones which are likely to be <= 16 MB.
Yes, there are floppies, but I think having over 3 MB available for
floppy DMA is plenty, and floppies are FINALLY going away...
-hpa
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 23:19 ` Linus Torvalds
2006-02-23 23:53 ` Rene Herman
@ 2006-02-24 14:11 ` Eric W. Biederman
1 sibling, 0 replies; 60+ messages in thread
From: Eric W. Biederman @ 2006-02-24 14:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rene Herman, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 23 Feb 2006, Rene Herman wrote:
>>
>> Okay. I suppose the only other option is to make "physical_start" a variable
>> passed in by the bootloader so that it could make a runtime decision? Ie,
>> place us at min(top_of_mem, 4G) if it cared to. I just grepped for
>> PHYSICAL_START and this didn't look _too_ bad.
Well the way to accomplish that is to just load the kernel there and
have it sort itself out. It would take a rev of the boot protocol
to let the bootloader know it was possible though.
> No can do. You'd have to make the kernel relocatable, and do load-time
> fixups. Very invasive.
Not really. With the linker able to generate the relocations you can
do it outside of most of the kernel where we have the decompressor.
Relocating a kernel is fundamentally an architecture dependent thing,
relocations can't work at all on x86-64 for example because of the narrow
window of virtual addresses it needs to run at.
I only haven't submitted the patches because I was too busy stabilizing
the reboot path last time I had time to be working in this area.
After I get some sleep I will dust off my patches and see how
it goes. x86-64 will probably have regressed but...
> It's certainly _possible_, but it's a whole new stage in the boot, one
> that we've never done before.
It isn't that new. There has been interest in this area from the
people working on the kdump stuff for a long you don't require
options under CONFIG_EMBEDDED to build a kernel for capturing a crash
dump.
CONFIG_PHYSICAL_START was supposed be the simple interim solution
until we could get relocation patches sorted out and merged.
Eric
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 19:35 ` Linus Torvalds
2006-02-23 19:44 ` Arjan van de Ven
2006-02-23 20:13 ` Rene Herman
@ 2006-02-24 1:38 ` Martin Bligh
2 siblings, 0 replies; 60+ messages in thread
From: Martin Bligh @ 2006-02-24 1:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rene Herman, Arjan van de Ven, Andi Kleen, linux-kernel, akpm,
mingo
Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Rene Herman wrote:
>
>>Also, did the kernel still boot on a 4M machine, and would it still do so with
>>the change to 4M as posted? 2.4 used to boot fine with 4M. Not certain anymore
>>if I ever tested that with 2.6 (and can't right now).
>
>
> If you want to boot a 4MB machine with the suggested patch, you'd have to
> enable CONFIG_EMBEDDED (something you'd likely want to do anyway, for a 4M
> machine), and turn the physical start address back down to 1MB.
>
> That's one reason I didn't make it 16MB. A 4MB machine is pretty damn
> embedded these days (you'd want to enable EMBEDDED just to turn off some
> other things that make the kernel bigger), but I can imagine that real
> people run Linux/x86 in 16MB as long as they don't run X.
ISTR from a long time ago, bootstrapping NUMA-Q, that in early boot we
only have the first 8MB mapped. Might have changed, and is probably
easily fixable, but ...
M.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:08 ` Linus Torvalds
` (2 preceding siblings ...)
2006-02-23 19:23 ` Rene Herman
@ 2006-02-23 20:07 ` Andy Whitcroft
3 siblings, 0 replies; 60+ messages in thread
From: Andy Whitcroft @ 2006-02-23 20:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Arjan van de Ven, Andi Kleen, linux-kernel, akpm, mingo
Linus Torvalds wrote:
> Does anybody want to run benchmarks? (Totally untested, may not boot,
> might physically accost your pets for all I know).
Will throw this into the nightly tests and see what pops out.
-apw
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
2006-02-23 16:00 ` Andi Kleen
@ 2006-02-23 16:48 ` Linus Torvalds
2006-02-23 16:54 ` Benjamin LaHaise
2006-02-23 18:01 ` Arjan van de Ven
2006-02-23 16:57 ` linux-os (Dick Johnson)
` (2 subsequent siblings)
4 siblings, 2 replies; 60+ messages in thread
From: Linus Torvalds @ 2006-02-23 16:48 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linux Kernel Mailing List, ak, Andrew Morton, Ingo Molnar
On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>
> 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.
I suspect we need architecture-specific profiles.
For example, on x86(-64), memcpy() is mostly inlined for the interesting
cases. That's not always so. Other architectures will have things like the
page copying and clearing as _the_ hottest functions. Same goes for
architecture-specific things like context switching etc, that have
different names on different architectures.
So putting the profile data in scripts/ doesn't sound very good.
That said, this certainly seems simple enough. I'd like to hear about
actual performance improvements with it before I'd apply anything like
this.
Also, since it's quite possible that being dense in the I$ is more of an
issue than being dense in the TLB (especially since almost everybody has
super-pages for kernel TLB entries and thus uses just a single entry - or
maybe a couple - for the kernel), it would probably make sense to try to
take calling patterns into account some way.
That's true of TLB usage too (in the absense of super-pages), of course.
But numbers talk.
Linus
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:48 ` Linus Torvalds
@ 2006-02-23 16:54 ` Benjamin LaHaise
2006-02-23 18:01 ` Arjan van de Ven
1 sibling, 0 replies; 60+ messages in thread
From: Benjamin LaHaise @ 2006-02-23 16:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Arjan van de Ven, Linux Kernel Mailing List, ak, Andrew Morton,
Ingo Molnar
On Thu, Feb 23, 2006 at 08:48:43AM -0800, Linus Torvalds wrote:
> For example, on x86(-64), memcpy() is mostly inlined for the interesting
> cases. That's not always so. Other architectures will have things like the
> page copying and clearing as _the_ hottest functions. Same goes for
> architecture-specific things like context switching etc, that have
> different names on different architectures.
On x86-64 the way gcc inlines memcpy() is rather broken, too. If the
kernel is compiled with -Os instead of -O2, gcc seems to always use
rep ; movs or rep ; stos, which is substantially slower (factor of 10
or more for some sizes -- a few parallel issued pipelined instructions
vs tieing up the entire pipeline until the size of the move is known and
dispatched) for small size data structures. Each instance fixed was
worth a few percent on the P4 when looking at lmbench's af_unix component.
-ben
--
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here
and they've asked us to stop the party." Don't Email: <dont@kvack.org>.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 16:48 ` Linus Torvalds
2006-02-23 16:54 ` Benjamin LaHaise
@ 2006-02-23 18:01 ` Arjan van de Ven
1 sibling, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 18:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, ak, Andrew Morton, Ingo Molnar
Linus Torvalds wrote:
>
> On Thu, 23 Feb 2006, Arjan van de Ven wrote:
>> 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.
>
> I suspect we need architecture-specific profiles.
>
> For example, on x86(-64), memcpy() is mostly inlined for the interesting
> cases. That's not always so. Other architectures will have things like the
> page copying and clearing as _the_ hottest functions. Same goes for
> architecture-specific things like context switching etc, that have
> different names on different architectures.
>
> So putting the profile data in scripts/ doesn't sound very good.
ok fair enough; that's easy to fix.
> That said, this certainly seems simple enough. I'd like to hear about
> actual performance improvements with it before I'd apply anything like
> this.
the results were sort of inconclusive (eg some wins, but some losses,
but mostly in the noise) in the "large" run done by the perf guys, so
I'm hoping to get another slot in testing soonish.
>
> Also, since it's quite possible that being dense in the I$ is more of an
> issue than being dense in the TLB (especially since almost everybody has
> super-pages for kernel TLB entries and thus uses just a single entry - or
> maybe a couple - for the kernel), it would probably make sense to try to
> take calling patterns into account some way.
or keep the existing order for a "hot set", but move all the cold ones
out. That way it'll at least not be worse than today
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
2006-02-23 16:00 ` Andi Kleen
2006-02-23 16:48 ` Linus Torvalds
@ 2006-02-23 16:57 ` linux-os (Dick Johnson)
2006-02-23 17:36 ` Zwane Mwaikambo
2006-02-24 22:19 ` Tony Luck
4 siblings, 0 replies; 60+ messages in thread
From: linux-os (Dick Johnson) @ 2006-02-23 16:57 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, ak, torvalds, akpm, mingo
On Thu, 23 Feb 2006, 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)
>
> This is done by enabling the -ffunction-sections flag in gcc, which puts
> each function in its own ELF section, so that the linker can then order them
> in a way defined by the linker script.
>
> As per previous discussions, Linus said he wanted a "static" list for this,
> eg a list provided by the kernel tarbal, so that most people have the same
> ordering at least. A script is provided to create this list based on
> readprofile(1) output. The included list is provisional, and entirely biased
> on my own testbox and me running a few kernel compiles and some other
> things.
>
> 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.
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
>
> ---
> arch/x86_64/Makefile | 1
> arch/x86_64/kernel/vmlinux.lds.S | 5
> scripts/functionlist | 1286 +++++++++++++++++++++++++++++++++++++++
> scripts/profile2linkerlist.pl | 21
> 4 files changed, 1313 insertions(+)
>
> Index: linux-2.6.16-reorder/arch/x86_64/Makefile
> ===================================================================
> --- linux-2.6.16-reorder.orig/arch/x86_64/Makefile
> +++ linux-2.6.16-reorder/arch/x86_64/Makefile
> @@ -35,6 +35,7 @@ CFLAGS += -m64
> CFLAGS += -mno-red-zone
> CFLAGS += -mcmodel=kernel
> CFLAGS += -pipe
> +CFLAGS += -ffunction-sections
> # this makes reading assembly source easier, but produces worse code
> # actually it makes the kernel smaller too.
> CFLAGS += -fno-reorder-blocks
> Index: linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
> ===================================================================
> --- linux-2.6.16-reorder.orig/arch/x86_64/kernel/vmlinux.lds.S
> +++ linux-2.6.16-reorder/arch/x86_64/kernel/vmlinux.lds.S
> @@ -20,7 +20,12 @@ SECTIONS
> phys_startup_64 = startup_64 - LOAD_OFFSET;
> _text = .; /* Text and read-only data */
> .text : AT(ADDR(.text) - LOAD_OFFSET) {
> + /* First the code that has to be first for bootstrapping */
> *(.bootstrap.text)
> + /* Then all the functions that are "hot" in profiles, to group them
> + onto the same hugetlb entry */
> + #include "../../../scripts/functionlist"
> + /* Then the rest */
> *(.text)
> SCHED_TEXT
> LOCK_TEXT
> Index: linux-2.6.16-reorder/scripts/functionlist
> ===================================================================
> --- /dev/null
> +++ linux-2.6.16-reorder/scripts/functionlist
> @@ -0,0 +1,1286 @@
> +*(.text.flush_thread)
> +*(.text.check_poison_obj)
> +*(.text.copy_page)
> +*(.text.__set_personality)
> +*(.text.gart_map_sg)
> +*(.text.kmem_cache_free)
> +*(.text.find_get_page)
> +*(.text._raw_spin_lock)
> +*(.text.ide_outb)
> +*(.text.unmap_vmas)
> +*(.text.copy_page_range)
> +*(.text.kprobe_handler)
> +*(.text.__handle_mm_fault)
> +*(.text.__d_lookup)
> +*(.text.copy_user_generic)
> +*(.text.__link_path_walk)
> +*(.text.get_page_from_freelist)
> +*(.text.kmem_cache_alloc)
> +*(.text.drive_cmd_intr)
> +*(.text.ia32_setup_sigcontext)
> +*(.text.huge_pte_offset)
> +*(.text.do_page_fault)
> +*(.text.page_remove_rmap)
> +*(.text.release_pages)
> +*(.text.ide_end_request)
> +*(.text.__mutex_lock_slowpath)
> +*(.text.__find_get_block)
> +*(.text.kfree)
> +*(.text.vfs_read)
> +*(.text._raw_spin_unlock)
> +*(.text.free_hot_cold_page)
> +*(.text.fget_light)
> +*(.text.schedule)
> +*(.text.memcmp)
> +*(.text.touch_atime)
> +*(.text.__might_sleep)
> +*(.text.__down_read_trylock)
> +*(.text.arch_pick_mmap_layout)
> +*(.text.find_vma)
> +*(.text.__make_request)
> +*(.text.do_generic_mapping_read)
> +*(.text.mutex_lock_interruptible)
> +*(.text.__generic_file_aio_read)
> +*(.text._atomic_dec_and_lock)
> +*(.text.__wake_up_bit)
> +*(.text.add_to_page_cache)
> +*(.text.cache_alloc_debugcheck_after)
> +*(.text.vm_normal_page)
> +*(.text.mutex_debug_check_no_locks_freed)
> +*(.text.net_rx_action)
> +*(.text.__find_first_zero_bit)
> +*(.text.put_page)
> +*(.text._raw_read_lock)
> +*(.text.__delay)
> +*(.text.dnotify_parent)
> +*(.text.do_path_lookup)
> +*(.text.do_sync_read)
> +*(.text.do_lookup)
> +*(.text.bit_waitqueue)
> +*(.text.file_read_actor)
> +*(.text.strncpy_from_user)
> +*(.text.__pagevec_lru_add_active)
> +*(.text.fget)
> +*(.text.dput)
> +*(.text.__strnlen_user)
> +*(.text.inotify_inode_queue_event)
> +*(.text.rw_verify_area)
> +*(.text.ide_intr)
> +*(.text.inotify_dentry_parent_queue_event)
> +*(.text.permission)
> +*(.text.memscan)
> +*(.text.hpet_rtc_interrupt)
> +*(.text.do_mmap_pgoff)
> +*(.text.current_fs_time)
> +*(.text.vfs_getattr)
> +*(.text.kmem_flagcheck)
> +*(.text.mark_page_accessed)
> +*(.text.free_pages_and_swap_cache)
> +*(.text.generic_fillattr)
> +*(.text.__block_prepare_write)
> +*(.text.__set_page_dirty_nobuffers)
> +*(.text.link_path_walk)
> +*(.text.find_get_pages_tag)
> +*(.text.ide_do_request)
> +*(.text.__alloc_pages)
> +*(.text.generic_permission)
> +*(.text.mod_page_state_offset)
> +*(.text.free_pgd_range)
> +*(.text.generic_file_buffered_write)
> +*(.text.number)
> +*(.text.ide_do_rw_disk)
> +*(.text.__brelse)
> +*(.text.__mod_page_state_offset)
> +*(.text.rotate_reclaimable_page)
> +*(.text.find_vma_prepare)
> +*(.text.find_vma_prev)
> +*(.text.lru_cache_add_active)
> +*(.text.__kmalloc_track_caller)
> +*(.text.smp_invalidate_interrupt)
> +*(.text.handle_IRQ_event)
> +*(.text.__find_get_block_slow)
> +*(.text.do_wp_page)
> +*(.text.do_select)
> +*(.text.set_user_nice)
> +*(.text.sys_read)
> +*(.text.do_munmap)
> +*(.text.csum_partial)
> +*(.text.__do_softirq)
> +*(.text.may_open)
> +*(.text.getname)
> +*(.text.get_empty_filp)
> +*(.text.__fput)
> +*(.text.remove_mapping)
> +*(.text.filp_ctor)
> +*(.text.poison_obj)
> +*(.text.unmap_region)
> +*(.text.test_set_page_writeback)
> +*(.text.__do_page_cache_readahead)
> +*(.text.sock_def_readable)
> +*(.text.ide_outl)
> +*(.text.shrink_zone)
> +*(.text.rb_insert_color)
> +*(.text.get_request)
> +*(.text.sys_pread64)
> +*(.text.spin_bug)
> +*(.text.ide_outsl)
> +*(.text.mask_and_ack_8259A)
> +*(.text.filemap_nopage)
> +*(.text.page_add_file_rmap)
> +*(.text.find_lock_page)
> +*(.text.tcp_poll)
> +*(.text.__mark_inode_dirty)
> +*(.text.file_ra_state_init)
> +*(.text.generic_file_llseek)
> +*(.text.__pagevec_lru_add)
> +*(.text.page_cache_readahead)
> +*(.text.n_tty_receive_buf)
> +*(.text.zonelist_policy)
> +*(.text.vma_adjust)
> +*(.text.test_clear_page_dirty)
> +*(.text.sync_buffer)
> +*(.text.do_exit)
> +*(.text.__bitmap_weight)
> +*(.text.alloc_pages_current)
> +*(.text.get_unused_fd)
> +*(.text.zone_watermark_ok)
> +*(.text.cpuset_update_task_memory_state)
> +*(.text.__bitmap_empty)
> +*(.text.sys_munmap)
> +*(.text.__inode_dir_notify)
> +*(.text.__generic_file_aio_write_nolock)
> +*(.text.__pte_alloc)
> +*(.text.sys_select)
> +*(.text.vm_acct_memory)
> +*(.text.vfs_write)
> +*(.text.__lru_add_drain)
> +*(.text.prio_tree_insert)
> +*(.text.generic_file_aio_read)
> +*(.text.vma_merge)
> +*(.text.block_write_full_page)
> +*(.text.__page_set_anon_rmap)
> +*(.text.apic_timer_interrupt)
> +*(.text.release_console_sem)
> +*(.text.sys_write)
> +*(.text.sys_brk)
> +*(.text.dup_mm)
> +*(.text.read_current_timer)
> +*(.text.ll_rw_block)
> +*(.text.blk_rq_map_sg)
> +*(.text.dbg_userword)
> +*(.text.__block_commit_write)
> +*(.text.cache_grow)
> +*(.text.copy_strings)
> +*(.text.release_task)
> +*(.text.do_sync_write)
> +*(.text.unlock_page)
> +*(.text.load_elf_binary)
> +*(.text.__follow_mount)
> +*(.text.__getblk)
> +*(.text.do_sys_open)
> +*(.text.current_kernel_time)
> +*(.text.call_rcu)
> +*(.text.write_chan)
> +*(.text.vsnprintf)
> +*(.text.dummy_inode_setsecurity)
> +*(.text.submit_bh)
> +*(.text.poll_freewait)
> +*(.text.bio_alloc_bioset)
> +*(.text.skb_clone)
> +*(.text.page_waitqueue)
> +*(.text.__mutex_lock_interruptible_slowpath)
> +*(.text.get_index)
> +*(.text.csum_partial_copy_generic)
> +*(.text.bad_range)
> +*(.text.remove_vma)
> +*(.text.cp_new_stat)
> +*(.text.alloc_arraycache)
> +*(.text.test_clear_page_writeback)
> +*(.text.strsep)
> +*(.text.open_namei)
> +*(.text._raw_read_unlock)
> +*(.text.get_vma_policy)
> +*(.text.__down_write_trylock)
> +*(.text.find_get_pages)
> +*(.text.tcp_rcv_established)
> +*(.text.generic_make_request)
> +*(.text.__block_write_full_page)
> +*(.text.cfq_set_request)
> +*(.text.sys_inotify_init)
> +*(.text.split_vma)
> +*(.text.__mod_timer)
> +*(.text.get_options)
> +*(.text.vma_link)
> +*(.text.mpage_writepages)
> +*(.text.truncate_complete_page)
> +*(.text.tcp_recvmsg)
> +*(.text.sigprocmask)
> +*(.text.filemap_populate)
> +*(.text.sys_close)
> +*(.text.inotify_dev_queue_event)
> +*(.text.do_task_stat)
> +*(.text.__dentry_open)
> +*(.text.unlink_file_vma)
> +*(.text.__pollwait)
> +*(.text.packet_rcv_spkt)
> +*(.text.drop_buffers)
> +*(.text.free_pgtables)
> +*(.text.generic_file_direct_write)
> +*(.text.copy_process)
> +*(.text.netif_receive_skb)
> +*(.text.dnotify_flush)
> +*(.text.print_bad_pte)
> +*(.text.anon_vma_unlink)
> +*(.text.sys_mprotect)
> +*(.text.sync_sb_inodes)
> +*(.text.find_inode_fast)
> +*(.text.dummy_inode_readlink)
> +*(.text.putname)
> +*(.text.init_smp_flush)
> +*(.text.dbg_redzone2)
> +*(.text.sk_run_filter)
> +*(.text.may_expand_vm)
> +*(.text.generic_file_aio_write)
> +*(.text.find_next_zero_bit)
> +*(.text.file_kill)
> +*(.text.audit_getname)
> +*(.text.arch_unmap_area_topdown)
> +*(.text.alloc_page_vma)
> +*(.text.tcp_transmit_skb)
> +*(.text.rb_next)
> +*(.text.dbg_redzone1)
> +*(.text.generic_file_mmap)
> +*(.text.vfs_fstat)
> +*(.text.sys_time)
> +*(.text.page_lock_anon_vma)
> +*(.text.get_unmapped_area)
> +*(.text.remote_llseek)
> +*(.text.__up_read)
> +*(.text.fd_install)
> +*(.text.eventpoll_init_file)
> +*(.text.dma_alloc_coherent)
> +*(.text.create_empty_buffers)
> +*(.text.__mutex_unlock_slowpath)
> +*(.text.dup_fd)
> +*(.text.d_alloc)
> +*(.text.tty_ldisc_try)
> +*(.text.sys_stime)
> +*(.text.__rb_rotate_right)
> +*(.text.d_validate)
> +*(.text.rb_erase)
> +*(.text.path_release)
> +*(.text.memmove)
> +*(.text.invalidate_complete_page)
> +*(.text.clear_inode)
> +*(.text.cache_estimate)
> +*(.text.alloc_buffer_head)
> +*(.text.smp_call_function_interrupt)
> +*(.text.flush_tlb_others)
> +*(.text.file_move)
> +*(.text.balance_dirty_pages_ratelimited)
> +*(.text.vma_prio_tree_add)
> +*(.text.timespec_trunc)
> +*(.text.mempool_alloc)
> +*(.text.iget_locked)
> +*(.text.d_alloc_root)
> +*(.text.cpuset_populate_dir)
> +*(.text.anon_vma_prepare)
> +*(.text.sys_newstat)
> +*(.text.alloc_page_interleave)
> +*(.text.__path_lookup_intent_open)
> +*(.text.__pagevec_free)
> +*(.text.inode_init_once)
> +*(.text.free_vfsmnt)
> +*(.text.__user_walk_fd)
> +*(.text.cfq_idle_slice_timer)
> +*(.text.sys_mmap)
> +*(.text.sys_llseek)
> +*(.text.prio_tree_remove)
> +*(.text.filp_close)
> +*(.text.file_permission)
> +*(.text.vma_prio_tree_remove)
> +*(.text.tcp_ack)
> +*(.text.nameidata_to_filp)
> +*(.text.sys_lseek)
> +*(.text.percpu_counter_mod)
> +*(.text.igrab)
> +*(.text.__bread)
> +*(.text.alloc_inode)
> +*(.text.filldir)
> +*(.text.__rb_rotate_left)
> +*(.text.irq_affinity_write_proc)
> +*(.text.init_request_from_bio)
> +*(.text.find_or_create_page)
> +*(.text.tty_poll)
> +*(.text.tcp_sendmsg)
> +*(.text.ide_wait_stat)
> +*(.text.free_buffer_head)
> +*(.text.flush_signal_handlers)
> +*(.text.tcp_v4_rcv)
> +*(.text.nr_blockdev_pages)
> +*(.text.locks_remove_flock)
> +*(.text.__iowrite32_copy)
> +*(.text.do_filp_open)
> +*(.text.try_to_release_page)
> +*(.text.page_add_new_anon_rmap)
> +*(.text.kmem_cache_size)
> +*(.text.eth_type_trans)
> +*(.text.try_to_free_buffers)
> +*(.text.schedule_tail)
> +*(.text.proc_lookup)
> +*(.text.no_llseek)
> +*(.text.kfree_skbmem)
> +*(.text.do_wait)
> +*(.text.do_mpage_readpage)
> +*(.text.vfs_stat_fd)
> +*(.text.tty_write)
> +*(.text.705)
> +*(.text.sync_page)
> +*(.text.__remove_shared_vm_struct)
> +*(.text.__kfree_skb)
> +*(.text.sock_poll)
> +*(.text.get_request_wait)
> +*(.text.do_sigaction)
> +*(.text.do_brk)
> +*(.text.tcp_event_data_recv)
> +*(.text.read_chan)
> +*(.text.pipe_writev)
> +*(.text.__emul_lookup_dentry)
> +*(.text.rtc_get_rtc_time)
> +*(.text.print_objinfo)
> +*(.text.file_update_time)
> +*(.text.do_signal)
> +*(.text.disable_8259A_irq)
> +*(.text.blk_queue_bounce)
> +*(.text.__anon_vma_link)
> +*(.text.__vma_link)
> +*(.text.vfs_rename)
> +*(.text.sys_newlstat)
> +*(.text.sys_newfstat)
> +*(.text.sys_mknod)
> +*(.text.__show_regs)
> +*(.text.iput)
> +*(.text.get_signal_to_deliver)
> +*(.text.flush_tlb_page)
> +*(.text.debug_mutex_wake_waiter)
> +*(.text.copy_thread)
> +*(.text.clear_page_dirty_for_io)
> +*(.text.buffer_io_error)
> +*(.text.vfs_permission)
> +*(.text.truncate_inode_pages_range)
> +*(.text.sys_recvfrom)
> +*(.text.remove_suid)
> +*(.text.mark_buffer_dirty)
> +*(.text.local_bh_enable)
> +*(.text.get_zeroed_page)
> +*(.text.get_vmalloc_info)
> +*(.text.flush_old_exec)
> +*(.text.dummy_inode_permission)
> +*(.text.__bio_add_page)
> +*(.text.prio_tree_replace)
> +*(.text.notify_change)
> +*(.text.mntput_no_expire)
> +*(.text.fput)
> +*(.text.__end_that_request_first)
> +*(.text.wake_up_bit)
> +*(.text.unuse_mm)
> +*(.text.skb_release_data)
> +*(.text.shrink_icache_memory)
> +*(.text.sched_balance_self)
> +*(.text.__pmd_alloc)
> +*(.text.pipe_poll)
> +*(.text.normal_poll)
> +*(.text.__free_pages)
> +*(.text.follow_mount)
> +*(.text.cdrom_start_packet_command)
> +*(.text.blk_recount_segments)
> +*(.text.bio_put)
> +*(.text.__alloc_skb)
> +*(.text.__wake_up)
> +*(.text.vm_stat_account)
> +*(.text.sys_fcntl)
> +*(.text.sys_fadvise64)
> +*(.text._raw_write_unlock)
> +*(.text.__pud_alloc)
> +*(.text.alloc_page_buffers)
> +*(.text.vfs_llseek)
> +*(.text.sockfd_lookup)
> +*(.text._raw_write_lock)
> +*(.text.put_compound_page)
> +*(.text.prune_dcache)
> +*(.text.pipe_readv)
> +*(.text.mempool_free)
> +*(.text.make_ahead_window)
> +*(.text.lru_add_drain)
> +*(.text.constant_test_bit)
> +*(.text.__clear_user)
> +*(.text.arch_unmap_area)
> +*(.text.anon_vma_link)
> +*(.text.sys_chroot)
> +*(.text.setup_arg_pages)
> +*(.text.radix_tree_preload)
> +*(.text.init_rwsem)
> +*(.text.generic_osync_inode)
> +*(.text.generic_delete_inode)
> +*(.text.do_sys_poll)
> +*(.text.dev_queue_xmit)
> +*(.text.default_llseek)
> +*(.text.__writeback_single_inode)
> +*(.text.vfs_ioctl)
> +*(.text.__up_write)
> +*(.text.unix_poll)
> +*(.text.sys_rt_sigprocmask)
> +*(.text.sock_recvmsg)
> +*(.text.recalc_bh_state)
> +*(.text.__put_unused_fd)
> +*(.text.process_backlog)
> +*(.text.locks_remove_posix)
> +*(.text.lease_modify)
> +*(.text.expand_files)
> +*(.text.end_buffer_read_nobh)
> +*(.text.d_splice_alias)
> +*(.text.debug_mutex_init_waiter)
> +*(.text.copy_from_user)
> +*(.text.cap_vm_enough_memory)
> +*(.text.show_vfsmnt)
> +*(.text.release_sock)
> +*(.text.pfifo_fast_enqueue)
> +*(.text.half_md4_transform)
> +*(.text.fs_may_remount_ro)
> +*(.text.do_fork)
> +*(.text.copy_hugetlb_page_range)
> +*(.text.cache_free_debugcheck)
> +*(.text.__tcp_select_window)
> +*(.text.task_handoff_register)
> +*(.text.sys_open)
> +*(.text.strlcpy)
> +*(.text.skb_copy_datagram_iovec)
> +*(.text.set_up_list3s)
> +*(.text.release_open_intent)
> +*(.text.qdisc_restart)
> +*(.text.n_tty_chars_in_buffer)
> +*(.text.inode_change_ok)
> +*(.text.__downgrade_write)
> +*(.text.debug_mutex_unlock)
> +*(.text.add_timer_randomness)
> +*(.text.sock_common_recvmsg)
> +*(.text.set_bh_page)
> +*(.text.printk_lock)
> +*(.text.path_release_on_umount)
> +*(.text.ip_output)
> +*(.text.ide_build_dmatable)
> +*(.text.__get_user_8)
> +*(.text.end_buffer_read_sync)
> +*(.text.__d_path)
> +*(.text.d_move)
> +*(.text.del_timer)
> +*(.text.constant_test_bit)
> +*(.text.blockable_page_cache_readahead)
> +*(.text.tty_read)
> +*(.text.sys_readlink)
> +*(.text.sys_faccessat)
> +*(.text.read_swap_cache_async)
> +*(.text.pty_write_room)
> +*(.text.page_address_in_vma)
> +*(.text.kthread)
> +*(.text.cfq_exit_io_context)
> +*(.text.__tcp_push_pending_frames)
> +*(.text.sys_pipe)
> +*(.text.submit_bio)
> +*(.text.pid_revalidate)
> +*(.text.page_referenced_file)
> +*(.text.lock_sock)
> +*(.text.get_page_state_node)
> +*(.text.generic_block_bmap)
> +*(.text.do_setitimer)
> +*(.text.dev_queue_xmit_nit)
> +*(.text.copy_from_read_buf)
> +*(.text.__const_udelay)
> +*(.text.console_conditional_schedule)
> +*(.text.wake_up_new_task)
> +*(.text.wait_for_completion_interruptible)
> +*(.text.tcp_rcv_rtt_update)
> +*(.text.sys_mlockall)
> +*(.text.set_fs_altroot)
> +*(.text.schedule_timeout)
> +*(.text.nr_free_pagecache_pages)
> +*(.text.nf_iterate)
> +*(.text.mapping_tagged)
> +*(.text.ip_queue_xmit)
> +*(.text.ip_local_deliver)
> +*(.text.follow_page)
> +*(.text.elf_map)
> +*(.text.dummy_file_permission)
> +*(.text.dispose_list)
> +*(.text.dentry_open)
> +*(.text.dentry_iput)
> +*(.text.bio_alloc)
> +*(.text.alloc_skb_from_cache)
> +*(.text.wait_on_page_bit)
> +*(.text.vfs_readdir)
> +*(.text.vfs_lstat)
> +*(.text.seq_escape)
> +*(.text.__posix_lock_file)
> +*(.text.mm_release)
> +*(.text.kref_put)
> +*(.text.ip_rcv)
> +*(.text.__iget)
> +*(.text.free_pages)
> +*(.text.find_mergeable_anon_vma)
> +*(.text.find_extend_vma)
> +*(.text.dummy_inode_listsecurity)
> +*(.text.bio_add_page)
> +*(.text.__vm_enough_memory)
> +*(.text.vfs_stat)
> +*(.text.tty_paranoia_check)
> +*(.text.tcp_read_sock)
> +*(.text.tcp_data_queue)
> +*(.text.sys_uname)
> +*(.text.sys_renameat)
> +*(.text.__strncpy_from_user)
> +*(.text.__mutex_init)
> +*(.text.__lookup_hash)
> +*(.text.kref_get)
> +*(.text.ip_route_input)
> +*(.text.__insert_inode_hash)
> +*(.text.do_sock_write)
> +*(.text.blk_done_softirq)
> +*(.text.__wake_up_sync)
> +*(.text.__vma_link_rb)
> +*(.text.tty_ioctl)
> +*(.text.tracesys)
> +*(.text.sys_getdents)
> +*(.text.sys_dup)
> +*(.text.stub_execve)
> +*(.text.sha_transform)
> +*(.text.radix_tree_tag_clear)
> +*(.text.put_unused_fd)
> +*(.text.put_files_struct)
> +*(.text.mpage_readpages)
> +*(.text.may_delete)
> +*(.text.kmem_cache_create)
> +*(.text.ip_mc_output)
> +*(.text.interleave_nodes)
> +*(.text.groups_search)
> +*(.text.generic_drop_inode)
> +*(.text.generic_commit_write)
> +*(.text.fcntl_setlk)
> +*(.text.exit_mmap)
> +*(.text.end_page_writeback)
> +*(.text.__d_rehash)
> +*(.text.debug_mutex_free_waiter)
> +*(.text.csum_ipv6_magic)
> +*(.text.count)
> +*(.text.cleanup_rbuf)
> +*(.text.check_spinlock_acquired_node)
> +*(.text.can_vma_merge_after)
> +*(.text.bio_endio)
> +*(.text.alloc_pidmap)
> +*(.text.write_ldt)
> +*(.text.vmtruncate_range)
> +*(.text.vfs_create)
> +*(.text.__user_walk)
> +*(.text.update_send_head)
> +*(.text.unmap_underlying_metadata)
> +*(.text.tty_ldisc_deref)
> +*(.text.tcp_setsockopt)
> +*(.text.tcp_send_ack)
> +*(.text.sys_pause)
> +*(.text.sys_gettimeofday)
> +*(.text.sync_dirty_buffer)
> +*(.text.strncmp)
> +*(.text.release_posix_timer)
> +*(.text.proc_file_read)
> +*(.text.prepare_to_wait)
> +*(.text.locks_mandatory_locked)
> +*(.text.interruptible_sleep_on_timeout)
> +*(.text.inode_sub_bytes)
> +*(.text.in_group_p)
> +*(.text.hrtimer_try_to_cancel)
> +*(.text.filldir64)
> +*(.text.fasync_helper)
> +*(.text.dummy_sb_pivotroot)
> +*(.text.d_lookup)
> +*(.text.d_instantiate)
> +*(.text.__d_find_alias)
> +*(.text.cpu_idle_wait)
> +*(.text.cond_resched_lock)
> +*(.text.chown_common)
> +*(.text.blk_congestion_wait)
> +*(.text.activate_page)
> +*(.text.unlock_buffer)
> +*(.text.tty_wakeup)
> +*(.text.tcp_v4_do_rcv)
> +*(.text.tcp_current_mss)
> +*(.text.sys_openat)
> +*(.text.sys_fchdir)
> +*(.text.strnlen_user)
> +*(.text.strnlen)
> +*(.text.strchr)
> +*(.text.sock_common_getsockopt)
> +*(.text.skb_checksum)
> +*(.text.remove_wait_queue)
> +*(.text.rb_replace_node)
> +*(.text.radix_tree_node_ctor)
> +*(.text.pty_chars_in_buffer)
> +*(.text.profile_hit)
> +*(.text.prio_tree_left)
> +*(.text.pgd_clear_bad)
> +*(.text.pfifo_fast_dequeue)
> +*(.text.page_referenced)
> +*(.text.open_exec)
> +*(.text.mmput)
> +*(.text.mm_init)
> +*(.text.__ide_dma_off_quietly)
> +*(.text.ide_dma_intr)
> +*(.text.hrtimer_start)
> +*(.text.get_io_context)
> +*(.text.__get_free_pages)
> +*(.text.find_first_zero_bit)
> +*(.text.file_free_rcu)
> +*(.text.dummy_socket_sendmsg)
> +*(.text.do_unlinkat)
> +*(.text.do_arch_prctl)
> +*(.text.destroy_inode)
> +*(.text.can_vma_merge_before)
> +*(.text.block_sync_page)
> +*(.text.block_prepare_write)
> +*(.text.bio_init)
> +*(.text.arch_ptrace)
> +*(.text.wake_up_inode)
> +*(.text.wait_on_retry_sync_kiocb)
> +*(.text.vma_prio_tree_next)
> +*(.text.tcp_rcv_space_adjust)
> +*(.text.__tcp_ack_snd_check)
> +*(.text.sys_utime)
> +*(.text.sys_recvmsg)
> +*(.text.sys_mremap)
> +*(.text.sys_bdflush)
> +*(.text.sleep_on)
> +*(.text.set_page_dirty_lock)
> +*(.text.seq_path)
> +*(.text.schedule_timeout_interruptible)
> +*(.text.sched_fork)
> +*(.text.rt_run_flush)
> +*(.text.profile_munmap)
> +*(.text.prepare_binprm)
> +*(.text.__pagevec_release_nonlru)
> +*(.text.m_show)
> +*(.text.lookup_mnt)
> +*(.text.__lookup_mnt)
> +*(.text.lock_timer_base)
> +*(.text.is_subdir)
> +*(.text.invalidate_bh_lru)
> +*(.text.init_buffer_head)
> +*(.text.ifind_fast)
> +*(.text.ide_dma_start)
> +*(.text.__get_page_state)
> +*(.text.flock_to_posix_lock)
> +*(.text.__find_symbol)
> +*(.text.do_futex)
> +*(.text.do_execve)
> +*(.text.dirty_writeback_centisecs_handler)
> +*(.text.dev_watchdog)
> +*(.text.can_share_swap_page)
> +*(.text.blkdev_put)
> +*(.text.bio_get_nr_vecs)
> +*(.text.xfrm_compile_policy)
> +*(.text.vma_prio_tree_insert)
> +*(.text.vfs_lstat_fd)
> +*(.text.__user_path_lookup_open)
> +*(.text.thread_return)
> +*(.text.tcp_send_delayed_ack)
> +*(.text.sock_def_error_report)
> +*(.text.shrink_slab)
> +*(.text.serial_out)
> +*(.text.seq_read)
> +*(.text.secure_ip_id)
> +*(.text.search_binary_handler)
> +*(.text.proc_pid_unhash)
> +*(.text.pagevec_lookup)
> +*(.text.new_inode)
> +*(.text.memcpy_toiovec)
> +*(.text.locks_free_lock)
> +*(.text.__lock_page)
> +*(.text.__lock_buffer)
> +*(.text.load_module)
> +*(.text.is_bad_inode)
> +*(.text.invalidate_inode_buffers)
> +*(.text.insert_vm_struct)
> +*(.text.inode_setattr)
> +*(.text.inode_add_bytes)
> +*(.text.ide_read_24)
> +*(.text.ide_get_error_location)
> +*(.text.ide_do_drive_cmd)
> +*(.text.get_locked_pte)
> +*(.text.get_filesystem_list)
> +*(.text.generic_file_open)
> +*(.text.follow_down)
> +*(.text.find_next_bit)
> +*(.text.__find_first_bit)
> +*(.text.exit_mm)
> +*(.text.exec_keys)
> +*(.text.end_buffer_write_sync)
> +*(.text.end_bio_bh_io_sync)
> +*(.text.dummy_socket_shutdown)
> +*(.text.d_rehash)
> +*(.text.d_path)
> +*(.text.do_ioctl)
> +*(.text.dget_locked)
> +*(.text.copy_thread_group_keys)
> +*(.text.cdrom_end_request)
> +*(.text.cap_bprm_apply_creds)
> +*(.text.blk_rq_bio_prep)
> +*(.text.__bitmap_intersects)
> +*(.text.bio_phys_segments)
> +*(.text.bio_free)
> +*(.text.arch_get_unmapped_area_topdown)
> +*(.text.writeback_in_progress)
> +*(.text.vfs_follow_link)
> +*(.text.tcp_rcv_state_process)
> +*(.text.tcp_check_space)
> +*(.text.sys_stat)
> +*(.text.sys_rt_sigreturn)
> +*(.text.sys_rt_sigaction)
> +*(.text.sys_remap_file_pages)
> +*(.text.sys_pwrite64)
> +*(.text.sys_fchownat)
> +*(.text.sys_fchmodat)
> +*(.text.strncat)
> +*(.text.strlcat)
> +*(.text.strcmp)
> +*(.text.steal_locks)
> +*(.text.sock_create)
> +*(.text.sk_stream_rfree)
> +*(.text.sk_stream_mem_schedule)
> +*(.text.skip_atoi)
> +*(.text.sk_alloc)
> +*(.text.show_stat)
> +*(.text.set_fs_pwd)
> +*(.text.set_binfmt)
> +*(.text.pty_unthrottle)
> +*(.text.proc_symlink)
> +*(.text.pipe_release)
> +*(.text.pageout)
> +*(.text.n_tty_write_wakeup)
> +*(.text.n_tty_ioctl)
> +*(.text.nr_free_zone_pages)
> +*(.text.migration_thread)
> +*(.text.mempool_free_slab)
> +*(.text.meminfo_read_proc)
> +*(.text.max_sane_readahead)
> +*(.text.lru_cache_add)
> +*(.text.kill_fasync)
> +*(.text.kernel_read)
> +*(.text.invalidate_mapping_pages)
> +*(.text.inode_has_buffers)
> +*(.text.init_once)
> +*(.text.inet_sendmsg)
> +*(.text.idedisk_issue_flush)
> +*(.text.generic_file_write)
> +*(.text.free_more_memory)
> +*(.text.__free_fdtable)
> +*(.text.filp_dtor)
> +*(.text.exit_sem)
> +*(.text.exit_itimers)
> +*(.text.error_interrupt)
> +*(.text.end_buffer_async_write)
> +*(.text.eligible_child)
> +*(.text.elf_map)
> +*(.text.dump_task_regs)
> +*(.text.dummy_task_setscheduler)
> +*(.text.dummy_socket_accept)
> +*(.text.dummy_file_free_security)
> +*(.text.__down_read)
> +*(.text.do_sock_read)
> +*(.text.do_sigaltstack)
> +*(.text.do_mremap)
> +*(.text.current_io_context)
> +*(.text.cpu_swap_callback)
> +*(.text.copy_vma)
> +*(.text.cap_bprm_set_security)
> +*(.text.blk_insert_request)
> +*(.text.bio_map_kern_endio)
> +*(.text.bio_hw_segments)
> +*(.text.bictcp_cong_avoid)
> +*(.text.add_interrupt_randomness)
> +*(.text.wait_for_completion)
> +*(.text.version_read_proc)
> +*(.text.unix_write_space)
> +*(.text.tty_ldisc_ref_wait)
> +*(.text.tty_ldisc_put)
> +*(.text.try_to_wake_up)
> +*(.text.tcp_v4_tw_remember_stamp)
> +*(.text.tcp_try_undo_dsack)
> +*(.text.tcp_may_send_now)
> +*(.text.sys_waitid)
> +*(.text.sys_sched_getparam)
> +*(.text.sys_getppid)
> +*(.text.sys_getcwd)
> +*(.text.sys_dup2)
> +*(.text.sys_chmod)
> +*(.text.sys_chdir)
> +*(.text.sprintf)
> +*(.text.sock_wfree)
> +*(.text.sock_aio_write)
> +*(.text.skb_drop_fraglist)
> +*(.text.skb_dequeue)
> +*(.text.set_close_on_exec)
> +*(.text.set_brk)
> +*(.text.seq_puts)
> +*(.text.SELECT_DRIVE)
> +*(.text.sched_exec)
> +*(.text.return_EIO)
> +*(.text.remove_from_page_cache)
> +*(.text.rcu_start_batch)
> +*(.text.__put_task_struct)
> +*(.text.proc_pid_readdir)
> +*(.text.proc_get_inode)
> +*(.text.prepare_to_wait_exclusive)
> +*(.text.pipe_wait)
> +*(.text.pipe_new)
> +*(.text.pdflush_operation)
> +*(.text.__pagevec_release)
> +*(.text.pagevec_lookup_tag)
> +*(.text.packet_rcv)
> +*(.text.n_tty_set_room)
> +*(.text.nr_free_pages)
> +*(.text.__net_timestamp)
> +*(.text.mpage_end_io_read)
> +*(.text.mod_timer)
> +*(.text.__memcpy)
> +*(.text.mb_cache_shrink_fn)
> +*(.text.lock_rename)
> +*(.text.kstrdup)
> +*(.text.is_ignored)
> +*(.text.int_very_careful)
> +*(.text.inotify_inode_is_dead)
> +*(.text.inotify_get_cookie)
> +*(.text.inode_get_bytes)
> +*(.text.init_timer)
> +*(.text.init_dev)
> +*(.text.inet_getname)
> +*(.text.ide_map_sg)
> +*(.text.__ide_dma_end)
> +*(.text.hrtimer_get_remaining)
> +*(.text.get_task_mm)
> +*(.text.get_random_int)
> +*(.text.free_pipe_info)
> +*(.text.filemap_write_and_wait_range)
> +*(.text.exit_thread)
> +*(.text.enter_idle)
> +*(.text.end_that_request_first)
> +*(.text.end_8259A_irq)
> +*(.text.dummy_file_alloc_security)
> +*(.text.do_group_exit)
> +*(.text.debug_mutex_init)
> +*(.text.cpuset_exit)
> +*(.text.cpu_idle)
> +*(.text.copy_semundo)
> +*(.text.copy_files)
> +*(.text.chrdev_open)
> +*(.text.cdrom_transfer_packet_command)
> +*(.text.cdrom_mode_sense)
> +*(.text.blk_phys_contig_segment)
> +*(.text.blk_get_queue)
> +*(.text.bio_split)
> +*(.text.audit_alloc)
> +*(.text.anon_pipe_buf_release)
> +*(.text.add_wait_queue_exclusive)
> +*(.text.add_wait_queue)
> +*(.text.acct_process)
> +*(.text.account)
> +*(.text.zeromap_page_range)
> +*(.text.yield)
> +*(.text.writeback_acquire)
> +*(.text.worker_thread)
> +*(.text.wait_on_page_writeback_range)
> +*(.text.__wait_on_buffer)
> +*(.text.vscnprintf)
> +*(.text.vmalloc_to_pfn)
> +*(.text.vgacon_save_screen)
> +*(.text.vfs_unlink)
> +*(.text.vfs_rmdir)
> +*(.text.unregister_md_personality)
> +*(.text.unlock_new_inode)
> +*(.text.unix_stream_sendmsg)
> +*(.text.unix_stream_recvmsg)
> +*(.text.unhash_process)
> +*(.text.udp_v4_lookup_longway)
> +*(.text.tty_ldisc_flush)
> +*(.text.tty_ldisc_enable)
> +*(.text.tty_hung_up_p)
> +*(.text.tty_buffer_free_all)
> +*(.text.tso_fragment)
> +*(.text.try_to_del_timer_sync)
> +*(.text.tcp_v4_err)
> +*(.text.tcp_unhash)
> +*(.text.tcp_seq_next)
> +*(.text.tcp_select_initial_window)
> +*(.text.tcp_sacktag_write_queue)
> +*(.text.tcp_cwnd_validate)
> +*(.text.sys_vhangup)
> +*(.text.sys_uselib)
> +*(.text.sys_symlink)
> +*(.text.sys_signal)
> +*(.text.sys_poll)
> +*(.text.sys_mount)
> +*(.text.sys_kill)
> +*(.text.sys_ioctl)
> +*(.text.sys_inotify_add_watch)
> +*(.text.sys_getuid)
> +*(.text.sys_getrlimit)
> +*(.text.sys_getitimer)
> +*(.text.sys_getgroups)
> +*(.text.sys_ftruncate)
> +*(.text.sysfs_lookup)
> +*(.text.sys_exit_group)
> +*(.text.stub_fork)
> +*(.text.sscanf)
> +*(.text.sock_map_fd)
> +*(.text.sock_get_timestamp)
> +*(.text.__sock_create)
> +*(.text.smp_call_function_single)
> +*(.text.sk_stop_timer)
> +*(.text.skb_copy_and_csum_datagram)
> +*(.text.__skb_checksum_complete)
> +*(.text.single_next)
> +*(.text.sigqueue_alloc)
> +*(.text.shrink_dcache_parent)
> +*(.text.select_idle_routine)
> +*(.text.run_workqueue)
> +*(.text.run_local_timers)
> +*(.text.remove_inode_hash)
> +*(.text.remove_dquot_ref)
> +*(.text.register_binfmt)
> +*(.text.read_cache_pages)
> +*(.text.rb_last)
> +*(.text.pty_open)
> +*(.text.proc_root_readdir)
> +*(.text.proc_pid_flush)
> +*(.text.proc_pident_lookup)
> +*(.text.proc_fill_super)
> +*(.text.proc_exe_link)
> +*(.text.posix_locks_deadlock)
> +*(.text.pipe_iov_copy_from_user)
> +*(.text.opost)
> +*(.text.nf_register_hook)
> +*(.text.netif_rx_ni)
> +*(.text.m_start)
> +*(.text.mpage_writepage)
> +*(.text.mm_alloc)
> +*(.text.memory_open)
> +*(.text.mark_buffer_async_write)
> +*(.text.lru_add_drain_all)
> +*(.text.locks_init_lock)
> +*(.text.locks_delete_lock)
> +*(.text.lock_hrtimer_base)
> +*(.text.load_script)
> +*(.text.__kill_fasync)
> +*(.text.ip_mc_sf_allow)
> +*(.text.__ioremap)
> +*(.text.int_with_check)
> +*(.text.int_sqrt)
> +*(.text.install_thread_keyring)
> +*(.text.init_page_buffers)
> +*(.text.inet_sock_destruct)
> +*(.text.idle_notifier_register)
> +*(.text.ide_execute_command)
> +*(.text.ide_end_drive_cmd)
> +*(.text.__ide_dma_host_on)
> +*(.text.hrtimer_run_queues)
> +*(.text.hpet_mask_rtc_irq_bit)
> +*(.text.__get_zone_counts)
> +*(.text.get_zone_counts)
> +*(.text.get_write_access)
> +*(.text.get_fs_struct)
> +*(.text.get_dirty_limits)
> +*(.text.generic_readlink)
> +*(.text.free_hot_page)
> +*(.text.finish_wait)
> +*(.text.find_inode)
> +*(.text.find_first_bit)
> +*(.text.__filemap_fdatawrite_range)
> +*(.text.__filemap_copy_from_user_iovec)
> +*(.text.exit_aio)
> +*(.text.elv_set_request)
> +*(.text.elv_former_request)
> +*(.text.dup_namespace)
> +*(.text.dupfd)
> +*(.text.dummy_socket_getsockopt)
> +*(.text.dummy_sb_post_mountroot)
> +*(.text.dummy_quotactl)
> +*(.text.dummy_inode_rename)
> +*(.text.__do_SAK)
> +*(.text.do_pipe)
> +*(.text.do_fsync)
> +*(.text.d_instantiate_unique)
> +*(.text.d_find_alias)
> +*(.text.deny_write_access)
> +*(.text.dentry_unhash)
> +*(.text.d_delete)
> +*(.text.datagram_poll)
> +*(.text.cpuset_fork)
> +*(.text.cpuid_read)
> +*(.text.copy_namespace)
> +*(.text.cond_resched)
> +*(.text.check_version)
> +*(.text.__change_page_attr)
> +*(.text.cfq_slab_kill)
> +*(.text.cfq_completed_request)
> +*(.text.cdrom_pc_intr)
> +*(.text.cdrom_decode_status)
> +*(.text.cap_capset_check)
> +*(.text.blk_put_request)
> +*(.text.bio_fs_destructor)
> +*(.text.bictcp_min_cwnd)
> +*(.text.alloc_chrdev_region)
> +*(.text.add_element)
> +*(.text.acct_update_integrals)
> +*(.text.write_boundary_block)
> +*(.text.writeback_release)
> +*(.text.writeback_inodes)
> +*(.text.wake_up_state)
> +*(.text.__wake_up_locked)
> +*(.text.wake_futex)
> +*(.text.wait_task_inactive)
> +*(.text.__wait_on_freeing_inode)
> +*(.text.wait_noreap_copyout)
> +*(.text.vmstat_start)
> +*(.text.vgacon_do_font_op)
> +*(.text.vfs_readv)
> +*(.text.vfs_quota_sync)
> +*(.text.update_queue)
> +*(.text.unshare_files)
> +*(.text.unmap_vm_area)
> +*(.text.unix_socketpair)
> +*(.text.unix_release_sock)
> +*(.text.unix_detach_fds)
> +*(.text.unix_create1)
> +*(.text.unix_bind)
> +*(.text.udp_sendmsg)
> +*(.text.udp_rcv)
> +*(.text.udp_queue_rcv_skb)
> +*(.text.uart_write)
> +*(.text.uart_startup)
> +*(.text.uart_open)
> +*(.text.tty_vhangup)
> +*(.text.tty_termios_baud_rate)
> +*(.text.tty_release)
> +*(.text.tty_ldisc_ref)
> +*(.text.throttle_vm_writeout)
> +*(.text.058)
> +*(.text.tcp_xmit_probe_skb)
> +*(.text.tcp_v4_send_check)
> +*(.text.tcp_v4_destroy_sock)
> +*(.text.tcp_sync_mss)
> +*(.text.tcp_snd_test)
> +*(.text.tcp_slow_start)
> +*(.text.tcp_send_fin)
> +*(.text.tcp_rtt_estimator)
> +*(.text.tcp_parse_options)
> +*(.text.tcp_ioctl)
> +*(.text.tcp_init_tso_segs)
> +*(.text.tcp_init_cwnd)
> +*(.text.tcp_getsockopt)
> +*(.text.tcp_fin)
> +*(.text.tcp_connect)
> +*(.text.tcp_cong_avoid)
> +*(.text.__tcp_checksum_complete_user)
> +*(.text.task_dumpable)
> +*(.text.sys_wait4)
> +*(.text.sys_utimes)
> +*(.text.sys_symlinkat)
> +*(.text.sys_socketpair)
> +*(.text.sys_rmdir)
> +*(.text.sys_readahead)
> +*(.text.sys_nanosleep)
> +*(.text.sys_linkat)
> +*(.text.sys_fstat)
> +*(.text.sysfs_readdir)
> +*(.text.sys_execve)
> +*(.text.sysenter_tracesys)
> +*(.text.sys_chown)
> +*(.text.stub_clone)
> +*(.text.strrchr)
> +*(.text.strncpy)
> +*(.text.stopmachine_set_state)
> +*(.text.sock_sendmsg)
> +*(.text.sock_release)
> +*(.text.sock_fasync)
> +*(.text.sock_close)
> +*(.text.sk_stream_write_space)
> +*(.text.sk_reset_timer)
> +*(.text.skb_split)
> +*(.text.skb_recv_datagram)
> +*(.text.skb_queue_tail)
> +*(.text.sk_attach_filter)
> +*(.text.si_swapinfo)
> +*(.text.simple_strtoll)
> +*(.text.set_termios)
> +*(.text.set_task_comm)
> +*(.text.set_shrinker)
> +*(.text.set_normalized_timespec)
> +*(.text.set_brk)
> +*(.text.serial_in)
> +*(.text.seq_printf)
> +*(.text.secure_dccp_sequence_number)
> +*(.text.rwlock_bug)
> +*(.text.rt_hash_code)
> +*(.text.__rta_fill)
> +*(.text.__request_resource)
> +*(.text.relocate_new_kernel)
> +*(.text.release_thread)
> +*(.text.release_mem)
> +*(.text.rb_prev)
> +*(.text.rb_first)
> +*(.text.random_poll)
> +*(.text.__put_super_and_need_restart)
> +*(.text.pty_write)
> +*(.text.ptrace_stop)
> +*(.text.proc_self_readlink)
> +*(.text.proc_root_lookup)
> +*(.text.proc_root_link)
> +*(.text.proc_pid_make_inode)
> +*(.text.proc_pid_attr_write)
> +*(.text.proc_lookupfd)
> +*(.text.proc_delete_inode)
> +*(.text.posix_same_owner)
> +*(.text.posix_block_lock)
> +*(.text.poll_initwait)
> +*(.text.pipe_write)
> +*(.text.pipe_read_fasync)
> +*(.text.pipe_ioctl)
> +*(.text.pdflush)
> +*(.text.pci_user_read_config_dword)
> +*(.text.page_readlink)
> +*(.text.null_lseek)
> +*(.text.nf_hook_slow)
> +*(.text.netlink_sock_destruct)
> +*(.text.netlink_broadcast)
> +*(.text.neigh_resolve_output)
> +*(.text.name_to_int)
> +*(.text.mwait_idle)
> +*(.text.mutex_trylock)
> +*(.text.mutex_debug_check_no_locks_held)
> +*(.text.m_stop)
> +*(.text.mpage_end_io_write)
> +*(.text.mpage_alloc)
> +*(.text.move_page_tables)
> +*(.text.mounts_open)
> +*(.text.__memset)
> +*(.text.memcpy_fromiovec)
> +*(.text.make_8259A_irq)
> +*(.text.lookup_user_key_possessed)
> +*(.text.lookup_create)
> +*(.text.locks_insert_lock)
> +*(.text.locks_alloc_lock)
> +*(.text.kthread_should_stop)
> +*(.text.kswapd)
> +*(.text.kobject_uevent)
> +*(.text.kobject_get_path)
> +*(.text.kobject_get)
> +*(.text.klist_children_put)
> +*(.text.__ip_route_output_key)
> +*(.text.ip_flush_pending_frames)
> +*(.text.ip_compute_csum)
> +*(.text.ip_append_data)
> +*(.text.ioc_set_batching)
> +*(.text.invalidate_inode_pages)
> +*(.text.__invalidate_device)
> +*(.text.install_arg_page)
> +*(.text.in_sched_functions)
> +*(.text.inotify_unmount_inodes)
> +*(.text.init_once)
> +*(.text.init_cdrom_command)
> +*(.text.inet_stream_connect)
> +*(.text.inet_sk_rebuild_header)
> +*(.text.inet_csk_addr2sockaddr)
> +*(.text.inet_create)
> +*(.text.ifind)
> +*(.text.ide_setup_dma)
> +*(.text.ide_outsw)
> +*(.text.ide_fixstring)
> +*(.text.ide_dma_setup)
> +*(.text.ide_cdrom_packet)
> +*(.text.ide_cd_put)
> +*(.text.ide_build_sglist)
> +*(.text.i8259A_shutdown)
> +*(.text.hung_up_tty_ioctl)
> +*(.text.hrtimer_nanosleep)
> +*(.text.hrtimer_init)
> +*(.text.hrtimer_cancel)
> +*(.text.hash_futex)
> +*(.text.group_send_sig_info)
> +*(.text.grab_cache_page_nowait)
> +*(.text.get_wchan)
> +*(.text.get_stack)
> +*(.text.get_page_state)
> +*(.text.getnstimeofday)
> +*(.text.get_node)
> +*(.text.get_kprobe)
> +*(.text.generic_unplug_device)
> +*(.text.free_task)
> +*(.text.frag_show)
> +*(.text.find_next_zero_string)
> +*(.text.filp_open)
> +*(.text.fillonedir)
> +*(.text.exit_io_context)
> +*(.text.exit_idle)
> +*(.text.exact_lock)
> +*(.text.eth_header)
> +*(.text.dummy_unregister_security)
> +*(.text.dummy_socket_post_create)
> +*(.text.dummy_socket_listen)
> +*(.text.dummy_quota_on)
> +*(.text.dummy_inode_follow_link)
> +*(.text.dummy_file_receive)
> +*(.text.dummy_file_mprotect)
> +*(.text.dummy_file_lock)
> +*(.text.dummy_file_ioctl)
> +*(.text.dummy_bprm_post_apply_creds)
> +*(.text.do_writepages)
> +*(.text.__down_interruptible)
> +*(.text.do_notify_resume)
> +*(.text.do_acct_process)
> +*(.text.del_timer_sync)
> +*(.text.default_rebuild_header)
> +*(.text.d_callback)
> +*(.text.dcache_readdir)
> +*(.text.ctrl_dumpfamily)
> +*(.text.cpuset_rmdir)
> +*(.text.copy_strings_kernel)
> +*(.text.con_write_room)
> +*(.text.complete_all)
> +*(.text.collect_sigign_sigcatch)
> +*(.text.clear_user)
> +*(.text.check_unthrottle)
> +*(.text.cdrom_release)
> +*(.text.cdrom_newpc_intr)
> +*(.text.cdrom_ioctl)
> +*(.text.cdrom_check_status)
> +*(.text.cdev_put)
> +*(.text.cdev_add)
> +*(.text.cap_ptrace)
> +*(.text.cap_bprm_secureexec)
> +*(.text.cache_alloc_refill)
> +*(.text.bmap)
> +*(.text.blk_run_queue)
> +*(.text.blk_queue_dma_alignment)
> +*(.text.blk_ordered_req_seq)
> +*(.text.blk_backing_dev_unplug)
> +*(.text.__bitmap_subset)
> +*(.text.__bitmap_and)
> +*(.text.bio_unmap_user)
> +*(.text.__bforget)
> +*(.text.bd_forget)
> +*(.text.bad_pipe_w)
> +*(.text.bad_get_user)
> +*(.text.audit_free)
> +*(.text.anon_vma_ctor)
> +*(.text.anon_pipe_buf_map)
> +*(.text.alloc_sock_iocb)
> +*(.text.alloc_fdset)
> +*(.text.aio_kick_handler)
> +*(.text.__add_entropy_words)
> +*(.text.add_disk_randomness)
> Index: linux-2.6.16-reorder/scripts/profile2linkerlist.pl
> ===================================================================
> --- /dev/null
> +++ linux-2.6.16-reorder/scripts/profile2linkerlist.pl
> @@ -0,0 +1,21 @@
> +#!/usr/bin/perl
> +
> +#
> +# Takes a (sorted) output of readprofile and turns it into a list suitable for
> +# linker scripts
> +#
> +# usage:
> +# readprofile | sort -rn | perl profile2linkerlist.pl > functionlist
> +#
> +
> +while (<>) {
> + my $line = $_;
> +
> + $_ =~ /\W*[0-9]+\W*([a-zA-Z\_0-9]+)\W*[0-9]+/;
> +
> + if ( ($line =~ /unknown/) || ($line =~ /total/)) {
> +
> + } else {
> + print "*(.text.$1)\n";
> + }
> +}
>
> -
This is the dumbest thing I've seen in recent years! You should
put all the stuff you want to hit with one TLB in a __single__
section and relocate that section!
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
` (2 preceding siblings ...)
2006-02-23 16:57 ` linux-os (Dick Johnson)
@ 2006-02-23 17:36 ` Zwane Mwaikambo
2006-02-23 17:59 ` Arjan van de Ven
2006-02-24 22:19 ` Tony Luck
4 siblings, 1 reply; 60+ messages in thread
From: Zwane Mwaikambo @ 2006-02-23 17:36 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, ak, torvalds, akpm, mingo
On Thu, 23 Feb 2006, 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)
Hello Arjan,
Assuming that functions defined in an object file are related and
hence benefit from cache spatial locality, doesn't this affect this
greatly? It would seem that with regards to the kernel image on x86, (2MB)
TLB usage isn't as scarce a resource as icache.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 17:36 ` Zwane Mwaikambo
@ 2006-02-23 17:59 ` Arjan van de Ven
0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-23 17:59 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel, ak, torvalds, akpm, mingo
Zwane Mwaikambo wrote:
> On Thu, 23 Feb 2006, 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)
>
> Hello Arjan,
> Assuming that functions defined in an object file are related and
> hence benefit from cache spatial locality, doesn't this affect this
> greatly? It would seem that with regards to the kernel image on x86, (2MB)
> TLB usage isn't as scarce a resource as icache.
this is probably a mixed blessing; right now frequent and non-frequent
code are highly intermixed, so even in the current situation the icache
isn't optimally used.
So what you sort of want is a thing better than pure "sort", a sort that
keeps existing order *within the hot functions*, but move the "cold"
ones out. That is thankfully independent of the infrastructure; I'll
keep that in mind when making the next version of the order list, it's a
good idea.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-23 15:09 ` Patch to reorder functions in the vmlinux to a defined order Arjan van de Ven
` (3 preceding siblings ...)
2006-02-23 17:36 ` Zwane Mwaikambo
@ 2006-02-24 22:19 ` Tony Luck
2006-02-24 22:21 ` Arjan van de Ven
4 siblings, 1 reply; 60+ messages in thread
From: Tony Luck @ 2006-02-24 22:19 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, ak, torvalds, akpm, mingo
On 2/23/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> As per previous discussions, Linus said he wanted a "static" list for this,
> eg a list provided by the kernel tarbal, so that most people have the same
> ordering at least. A script is provided to create this list based on
> readprofile(1) output. The included list is provisional, and entirely biased
> on my own testbox and me running a few kernel compiles and some other
> things.
>
> 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.
1) How will this work in the face of CONFIG options that change the
list of symbols present in your kernel? E.g. my hot oprofile list
might well contain a bunch of symbols from my NIC driver and whatever
filesystem I'm pounding on.
2) If you add enough lists from enough people, perhaps you'll get enough
coverage of the kernel with all their different workloads, that you'll have
too much to fit into the 2M page.
-Tony (Just joining in this thread for fun, ia64 pins all kernel text with a
single mapping, so we don't have any TLB misses at all :)
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: Patch to reorder functions in the vmlinux to a defined order
2006-02-24 22:19 ` Tony Luck
@ 2006-02-24 22:21 ` Arjan van de Ven
0 siblings, 0 replies; 60+ messages in thread
From: Arjan van de Ven @ 2006-02-24 22:21 UTC (permalink / raw)
To: Tony Luck; +Cc: linux-kernel, ak, torvalds, akpm, mingo
Tony Luck wrote:
> On 2/23/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
>> As per previous discussions, Linus said he wanted a "static" list for this,
>> eg a list provided by the kernel tarbal, so that most people have the same
>> ordering at least. A script is provided to create this list based on
>> readprofile(1) output. The included list is provisional, and entirely biased
>> on my own testbox and me running a few kernel compiles and some other
>> things.
>>
>> 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.
>
> 1) How will this work in the face of CONFIG options that change the
> list of symbols present in your kernel? E.g. my hot oprofile list
> might well contain a bunch of symbols from my NIC driver and whatever
> filesystem I'm pounding on.
that is fine; symbols that aren't actually present just are ignored by
the linker in this case
>
> 2) If you add enough lists from enough people, perhaps you'll get enough
> coverage of the kernel with all their different workloads, that you'll have
> too much to fit into the 2M page.
I am more optimistic; the total kernel size in "distro" configuration is
about 3.5Mb. I would find it hard to believe that more than half of that
is "hot" code even in a "many people send their profiles" setup.
^ permalink raw reply [flat|nested] 60+ messages in thread