scsi/qlogicpti.c section fixes
Subsystems (2)
PATCH 1/1 scsi/qlogicpti.c section fixes
This patch fixes the following section mismatches:
<-- snip -->
...
WARNING: drivers/scsi/qlogicpti.o(.devexit.text+0x8): Section mismatch in reference from the function qpti_sbus_remove() to the function .init.text:qpti_chain_del()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x56c): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_map_regs()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x580): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_register_irq()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x594): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_get_scsi_id()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x5b8): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_map_queues()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x780): Section mismatch in reference from the function qpti_sbus_probe() to the function .init.text:qpti_chain_add()
...
<-- snip -->
---
drivers/scsi/qlogicpti.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
3d89831963c0b6f62b24fc4b9dfe1c10d7f90d1b
drivers/scsi/qlogicpti.c +6 -6
@@ -651,7 +651,7 @@ static int qlogicpti_verify_tmon(struct qlogicpti *qpti)static irqreturn_t qpti_intr (int irq,void *dev_id); -static void __init qpti_chain_add (struct qlogicpti *qpti) +static void __devinit qpti_chain_add (struct qlogicpti *qpti) {spin_lock_irq (&qptichain_lock);if (qptichain !=NULL ) {
@@ -667,7 +667,7 @@ static void __init qpti_chain_add(struct qlogicpti *qpti)spin_unlock_irq (&qptichain_lock); } -static void __init qpti_chain_del (struct qlogicpti *qpti) +static void __devexit qpti_chain_del(struct qlogicpti *qpti) {spin_lock_irq (&qptichain_lock);if (qptichain == qpti) {
@@ -682,7 +682,7 @@ static void __init qpti_chain_del(struct qlogicpti *qpti)spin_unlock_irq (&qptichain_lock); } -static int __init qpti_map_regs (struct qlogicpti *qpti) +static int __devinit qpti_map_regs (struct qlogicpti *qpti) {struct sbus_dev *sdev = qpti->sdev;
@@ -705,7 +705,7 @@ static int __init qpti_map_regs(struct qlogicpti *qpti)return 0 ; } -static int __init qpti_register_irq (struct qlogicpti *qpti) +static int __devinit qpti_register_irq (struct qlogicpti *qpti) {struct sbus_dev *sdev = qpti->sdev;
@@ -730,7 +730,7 @@ fail:return -1 ; } -static void __init qpti_get_scsi_id (struct qlogicpti *qpti) +static void __devinit qpti_get_scsi_id (struct qlogicpti *qpti) { qpti->scsi_id = prom_getintdefault(qpti->prom_node, "initiator-id",
@@ -783,7 +783,7 @@ static void qpti_get_clock(struct qlogicpti *qpti)/* The request and response queues must each be aligned * on a page boundary. */ -static int __init qpti_map_queues (struct qlogicpti *qpti) +static int __devinit qpti_map_queues (struct qlogicpti *qpti) {struct sbus_dev *sdev = qpti->sdev;
James Bottomley
maintainerQuoted 4 lines · Adrian Bunk
This patch fixes the following section mismatches:
<-- snip -->
Quoted 8 lines
...
WARNING: drivers/scsi/qlogicpti.o(.devexit.text+0x8): Section mismatch in reference from the functionqpti_sbus_remove()to the function .init.text:qpti_chain_del()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x56c): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_regs()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x580): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_register_irq()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x594): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_get_scsi_id()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x5b8): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_queues()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x780): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_chain_add()
...
OK, look, this is really getting out of hand.
__init is possibly justifiable with a few hundred k savings on boot. __devinit and the rest are surely killable on the grounds they provide little benefit for all the pain they cause.
all __exit seems to do is set us up for unreferenced pointers in discarded sections, so could we kill that too?
James
Quoted 15 lines · James Bottomley
Quoted 4 lines · Adrian Bunk
This patch fixes the following section mismatches:
<-- snip -->
Quoted 8 lines
...
WARNING: drivers/scsi/qlogicpti.o(.devexit.text+0x8): Section mismatch in reference from the functionqpti_sbus_remove()to the function .init.text:qpti_chain_del()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x56c): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_regs()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x580): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_register_irq()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x594): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_get_scsi_id()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x5b8): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_queues()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x780): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_chain_add()
...
Quoted 1 line
OK, look, this is really getting out of hand.
We now at last have some infrastructure that does proper consistency check of the use of annotation.
So it is by no means getting out-of-hands..
To my understanding Adrian just fixed a potential oops. You have a driver that surely are thought to be hotplugable - otherwise qpti_sbus_probe() would not have been annotated __devinit. And had it ever been hotplugged then you had called a function in a __init section that was long gone.
Quoted 3 lines
__initis possibly justifiable with a few hundred k savings on boot.__devinitand the rest are surely killable on the grounds they provide little benefit for all the pain they cause.
For the embedded people a few kb here and there is worth it.
Quoted 2 lines
all
__exitseems to do is set us up for unreferenced pointers in discarded sections, so could we kill that too?
Again - savings when we build-in the drivers.
And without the checks we see 'funny' linker errors on the architectues that can continue to add the .exit.text in /DISCARD/
Sam
Quoted 8 lines · Sam Ravnborg
On Wed, Jan 30, 2008 at 03:00:16PM -0600, James Bottomley wrote:
...
To my understanding Adrian just fixed a potential oops. You have a driver that surely are thought to be hotplugable - otherwiseqpti_sbus_probe()would not have been annotated__devinit. And had it ever been hotplugged then you had called a function in a__initsection that was long gone.
...
s/had it ever been hotplugged/had it been hotplugged with a kernel
compiled with gcc 3.2 or 3.3/
Quoted 1 line
Sam
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedJames Bottomley
maintainerQuoted 21 lines · Sam Ravnborg
Quoted 15 lines · James Bottomley
Quoted 4 lines · Adrian Bunk
This patch fixes the following section mismatches:
<-- snip -->
Quoted 8 lines
...
WARNING: drivers/scsi/qlogicpti.o(.devexit.text+0x8): Section mismatch in reference from the functionqpti_sbus_remove()to the function .init.text:qpti_chain_del()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x56c): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_regs()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x580): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_register_irq()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x594): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_get_scsi_id()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x5b8): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_queues()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x780): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_chain_add()
...Quoted 1 line
OK, look, this is really getting out of hand.
We now at last have some infrastructure that does proper consistency check of the use of annotation.
So it is by no means getting out-of-hands..
Quoted 5 lines
To my understanding Adrian just fixed a potential oops. You have a driver that surely are thought to be hotplugable - otherwise
qpti_sbus_probe()would not have been annotated__devinit. And had it ever been hotplugged then you had called a function in a__initsection that was long gone.
I never said it didn't fix a bug. I'm just reflecting that all of the problems would go away and we'd save thousands of person hours on the infrastructure and bug fixing if we simply #defined most of the sectional annotations to be nops.
My basic question is "is the value of what all of this buys us (basically a few hundred k in savings)" worth all the investment we're putting into it. Particularly as it looks like that investment is becoming increasingly expensive.
Quoted 10 lines
Quoted 3 lines
__initis possibly justifiable with a few hundred k savings on boot.__devinitand the rest are surely killable on the grounds they provide little benefit for all the pain they cause.For the embedded people a few kb here and there is worth it.
Quoted 2 lines
all
__exitseems to do is set us up for unreferenced pointers in discarded sections, so could we kill that too?Again - savings when we build-in the drivers.
And without the checks we see 'funny' linker errors on the architectues that can continue to add the .exit.text in /DISCARD/
Perhaps you have different figures, but my standard kernel linking ones tell me that the discard sections only save tens of k (not hundreds that the init ones save), so I really do think they have no real benefit and land us huge problems of pointer references into discarded sections.
I don't deny we can invest large amounts of work to fix our current issues and build large scriptable checks to ensure we keep it fixed ... I'm just asking if, at the end of the day, it's really worth it.
James
Quoted 4 lines
I'm just reflecting that all of the
problems would go away and we'd save thousands of person hours on the infrastructure and bug fixing if we simply #defined most of the sectional annotations to be nops.
So far I have only seen three persons being really active in fixing the section mismatch bugs. And thats Randy, Adrian and myself. Granted a few other have done some sporadic efforts in their area of interest but nothing covering the tree as a whole. And most isssues are easy fixable - I would estimate less than half an hour in average for the fixes Adrian posted today. There are some tricky corners that are dfficult to deal with but I have not seen these occur in drivers.
It is mostly when we mix assembler and C plus
some of the core functionality.
The hotplug cpu stuff for example look scary and here
I may try to road you propose but for the hotplug stuff
I think it is worth it.
Sam
Value of __*{init,exit} anotations?
In reply to James BottomleyQuoted 14 lines · James Bottomley
Quoted 1 line · Sam Ravnborg
On Wed, Jan 30, 2008 at 03:00:16PM -0600, James Bottomley wrote:
...
Quoted 10 lines
Quoted 3 lines
__initis possibly justifiable with a few hundred k savings on boot.__devinitand the rest are surely killable on the grounds they provide little benefit for all the pain they cause.For the embedded people a few kb here and there is worth it.
Quoted 2 lines
all
__exitseems to do is set us up for unreferenced pointers in discarded sections, so could we kill that too?Again - savings when we build-in the drivers.
And without the checks we see 'funny' linker errors on the architectues that can continue to add the .exit.text in /DISCARD/
Quoted 8 lines
Perhaps you have different figures, but my standard kernel linking ones tell me that the discard sections only save tens of k (not hundreds that the init ones save), so I really do think they have no real benefit and land us huge problems of pointer references into discarded sections.
I don't deny we can invest large amounts of work to fix our current issues and build large scriptable checks to ensure we keep it fixed ... I'm just asking if, at the end of the day, it's really worth it.
Some people consider it worth it for their memory restricted systems and would like to drive the annotations even further. [1]
My experience while fixing section bugs during the last years is that the __dev{init,exit}* are actually the main question since they are both the majority of annotations and the ones that bring benefits only in a case that has become very exotic (CONFIG_HOTPLUG=n).
All the other annotations either both bring value for everyone (plain __init* and __exit*) or are nothing normal drivers would use (__cpu* and _mem*).
People at linux-arch (Cc'ed) might be better at explaining how often CONFIG_HOTPLUG gets used in real-life systems and how big the savings are there.
That might be a good basis for deciding whether it's worth it.
Quoted 1 line
James
cu
Adrian
[1] http://lkml.org/lkml/2007/10/12/297
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedJames Bottomley
maintainerRe: Value of __*{init,exit} anotations?
Quoted 36 lines · Adrian Bunk
Quoted 14 lines · James Bottomley
Quoted 1 line · Sam Ravnborg
On Wed, Jan 30, 2008 at 03:00:16PM -0600, James Bottomley wrote:
...
Quoted 10 lines
Quoted 3 lines
__initis possibly justifiable with a few hundred k savings on boot.__devinitand the rest are surely killable on the grounds they provide little benefit for all the pain they cause.For the embedded people a few kb here and there is worth it.
Quoted 2 lines
all
__exitseems to do is set us up for unreferenced pointers in discarded sections, so could we kill that too?Again - savings when we build-in the drivers.
And without the checks we see 'funny' linker errors on the architectues that can continue to add the .exit.text in /DISCARD/Quoted 8 lines
Perhaps you have different figures, but my standard kernel linking ones tell me that the discard sections only save tens of k (not hundreds that the init ones save), so I really do think they have no real benefit and land us huge problems of pointer references into discarded sections.
I don't deny we can invest large amounts of work to fix our current issues and build large scriptable checks to ensure we keep it fixed ... I'm just asking if, at the end of the day, it's really worth it.
Some people consider it worth it for their memory restricted systems and would like to drive the annotations even further. [1]
My experience while fixing section bugs during the last years is that the __dev{init,exit}* are actually the main question since they are both the majority of annotations and the ones that bring benefits only in a case that has become very exotic (
CONFIG_HOTPLUG=n).All the other annotations either both bring value for everyone (plain __init* and __exit*) or are nothing normal drivers would use (__cpu* and _mem*).
Quoted 5 lines
People at linux-arch (Cc'ed) might be better at explaining how often
CONFIG_HOTPLUGgets used in real-life systems and how big the savings are there.That might be a good basis for deciding whether it's worth it.
I'll certainly buy this. Perhaps killing everything other than __init and __exit (meaning discardable whether the system is hotplug, suspend or whatever) might get rid of 90% of the problem while still preserving 90% of the benefits. I think a lot of the issues do come from confusion over whether it should be __init, __devinint etc .
We can argue later over the benefit of __exit ...
James
Re: Value of __*{init,exit} anotations?
Quoted 5 lines · James Bottomley
Quoted 4 lines · Adrian Bunk
People at linux-arch (Cc'ed) might be better at explaining how often
CONFIG_HOTPLUGgets used in real-life systems and how big the savings are there.
Quoted 7 lines
Quoted 1 line
That might be a good basis for deciding whether it's worth it.
I'll certainly buy this. Perhaps killing everything other than
__initand__exit(meaning discardable whether the system is hotplug, suspend or whatever) might get rid of 90% of the problem while still preserving 90% of the benefits. I think a lot of the issues do come from confusion over whether it should be__init,__devinintetc .
Just looking at HOTPLUG on ARM by a simple grep, 57 default configurations for various machines are hotplug enabled out of 75 - so it's roughly 75%. Whether that 25% remainder cares or not, I'm not sure.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Re: Value of __*{init,exit} anotations?
In reply to Adrian BunkQuoted 3 lines
Some people consider it worth it for their memory restricted systems and would like to drive the annotations even further. [1]
They could get much better bang-for-the-buck (as in memory saved for amount of work invested) by tackling some the dynamic memory allocation pigs.
In general it's a trade off between how much work and patch churn versus benefit, and some of the annotations really don't look too good on this scale.
Quoted 3 lines
People at linux-arch (Cc'ed) might be better at explaining how often
CONFIG_HOTPLUGgets used in real-life systems and how big the savings are there.
CONFIG_HOTPLUG is widely used for suspend on multi core systems.
-Andi
Re: Value of __*{init,exit} anotations?
In reply to Adrian BunkQuoted 5 lines
Quoted 4 lines
I don't deny we can invest large amounts of work to fix our current issues and build large scriptable checks to ensure we keep it fixed ... I'm just asking if, at the end of the day, it's really worth it.
Quoted 7 lines
Some people consider it worth it for their memory restricted systems and would like to drive the annotations even further. [1]
My experience while fixing section bugs during the last years is that the __dev{init,exit}* are actually the main question since they are both the majority of annotations and the ones that bring benefits only in a case that has become very exotic (
CONFIG_HOTPLUG=n).
Some numbers...
I my current tree with an allyesconfig build for x86 64bit I see:
136 Section mismatch warnings in total
99 Section mismatch warnings from drivers/
This is with a few patches of mine applied but none of the recently posted fixes by Adrian.
I am concentrating on:drivers/pci/kernel/mm/
Will post my patches during the weekend if things goes well. There are some low hanging fruits in drivers/ but I stay away from these from now expecting others to fix these.
Sam
James Bottomley
maintainerPATCH 1/1 kill hotplug init/exit section annotations
No-one seems to see much value in these, and they cause about 90% of our problems with __init/__exit markers, so simply eliminate them. Rather than run over the whole tree removing them, this patch #defines them to be nops.
---
I'll probably be going after __exit after this one, but it makes sense to split them up, since the hotplug annotation removal looks uncontroversial, whereas __exit and discard section removal might produce more robust debate. I also think doing the hotplug removal gives us 90% of the benefits and removes 90% of the section mismatch problems.
James
include/asm-generic/vmlinux.lds.h +0 -65
@@ -9,46 +9,11 @@/* Align . to a 8 byte boundary equals to maximum function alignment. */ #define ALIGN_FUNCTION () . = ALIGN(8) -/* The actual configuration determine if the init/exit sections -* are handled as text/data or they can be discarded (which -* often happens at runtime) -*/ -#ifdef CONFIG_HOTPLUG -#define DEV_KEEP (sec) *(.dev##sec) -#define DEV_DISCARD (sec) -#else -#define DEV_KEEP (sec) -#define DEV_DISCARD (sec) *(.dev##sec) -#endif - -#ifdef CONFIG_HOTPLUG_CPU -#define CPU_KEEP (sec) *(.cpu##sec) -#define CPU_DISCARD (sec) -#else -#define CPU_KEEP (sec) -#define CPU_DISCARD (sec) *(.cpu##sec) -#endif - -#if defined(CONFIG_MEMORY_HOTPLUG ) -#define MEM_KEEP (sec) *(.mem##sec) -#define MEM_DISCARD (sec) -#else -#define MEM_KEEP (sec) -#define MEM_DISCARD (sec) *(.mem##sec) -#endif - -/* .data section */ #define DATA_DATA \ *(.data) \ *(.data.init.refok) \ *(.ref.data) \ - DEV_KEEP(init.data) \ - DEV_KEEP(exit.data) \ - CPU_KEEP(init.data) \ - CPU_KEEP(exit.data) \ - MEM_KEEP(init.data) \ - MEM_KEEP(exit.data) \ . = ALIGN(8); \ VMLINUX_SYMBOL(__start___markers) = .; \ *(__markers) \
@@ -171,12 +136,6 @@/* __*init sections */ \ __init_rodata : AT(ADDR(__init_rodata) - LOAD_OFFSET) { \ *(.ref.rodata) \ - DEV_KEEP(init.rodata) \ - DEV_KEEP(exit.rodata) \ - CPU_KEEP(init.rodata) \ - CPU_KEEP(exit.rodata) \ - MEM_KEEP(init.rodata) \ - MEM_KEEP(exit.rodata) \ } \ \/* Built-in module parameters. */ \
@@ -208,12 +167,6 @@ *(.ref.text) \ *(.text.init.refok) \ *(.exit.text.refok) \ - DEV_KEEP(init.text) \ - DEV_KEEP(exit.text) \ - CPU_KEEP(init.text) \ - CPU_KEEP(exit.text) \ - MEM_KEEP(init.text) \ -MEM_KEEP (exit.text)/* sched.text is aling to function alignment to secure we have same
@@ -241,33 +194,15 @@/* init and exit section handling */ #define INIT_DATA \ *(.init.data) \ - DEV_DISCARD(init.data) \ - DEV_DISCARD(init.rodata) \ - CPU_DISCARD(init.data) \ - CPU_DISCARD(init.rodata) \ - MEM_DISCARD(init.data) \ - MEM_DISCARD(init.rodata)#define INIT_TEXT \ *(.init.text) \ - DEV_DISCARD(init.text) \ - CPU_DISCARD(init.text) \ - MEM_DISCARD(init.text)#define EXIT_DATA \ *(.exit.data) \ - DEV_DISCARD(exit.data) \ - DEV_DISCARD(exit.rodata) \ - CPU_DISCARD(exit.data) \ - CPU_DISCARD(exit.rodata) \ - MEM_DISCARD(exit.data) \ - MEM_DISCARD(exit.rodata)#define EXIT_TEXT \ *(.exit.text) \ - DEV_DISCARD(exit.text) \ - CPU_DISCARD(exit.text) \ - MEM_DISCARD(exit.text)/* DWARF debug sections. Symbols in the DWARF debugging sections are relative to
include/linux/init.h +26 -27
69 lines not on this page · raw message
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 7 lines · On Thu, 31 Jan 2008 09:57:31 -0600 James Bottomley…
No-one seems to see much value in these, and they cause about 90% of our problems with __init/__exit markers, so simply eliminate them. Rather than run over the whole tree removing them, this patch #defines them to be nops.
Signed-off-by James Bottomley <[email protected]>
Quoted 8 lines
---
I'll probably be going after
__exitafter this one, but it makes sense to split them up, since the hotplug annotation removal looks uncontroversial, whereas__exitand discard section removal might produce more robust debate. I also think doing the hotplug removal gives us 90% of the benefits and removes 90% of the section mismatch problems.
Since hotplug is so fundamental nowadays the value no longer outweighs the pain/cost to me, so
Signature · 3 lines
If you want to reach me at my work email, use [email protected] For development, discussion and tips for power savings, visit http://www.lesswatts.org
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 20 lines · Arjan van de Ven
Quoted 7 lines · On Thu, 31 Jan 2008 09:57:31 -0600 James Bottomley…
No-one seems to see much value in these, and they cause about 90% of our problems with __init/__exit markers, so simply eliminate them. Rather than run over the whole tree removing them, this patch #defines them to be nops.
Signed-off-by James Bottomley <[email protected]>Quoted 8 lines
---
I'll probably be going after
__exitafter this one, but it makes sense to split them up, since the hotplug annotation removal looks uncontroversial, whereas__exitand discard section removal might produce more robust debate. I also think doing the hotplug removal gives us 90% of the benefits and removes 90% of the section mismatch problems.
Quoted 2 lines
Since hotplug is so fundamental nowadays the value no longer outweighs the pain/cost to me, so
Granted for normal hotplug.
But my computer has neither CPU hotplug not memory hotplug, and I don't see the point for removing these annotations (and they are anyway not what causes problems in normal drivers).
Quoted 1 line
Acked-by Arjan van de Ven <[email protected]>
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: [PATCH] kill hotplug init/exit section annotations
Quoted 22 lines · On Thu, 31 Jan 2008 18:21:42 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 21 lines · Arjan van de Ven
Quoted 16 lines · On Thu, 31 Jan 2008 09:57:31 -0600 James Bottomley…
No-one seems to see much value in these, and they cause about 90% of our problems with __init/__exit markers, so simply eliminate them. Rather than run over the whole tree removing them, this patch #defines them to be nops.
Signed-off-by: James Bottomley
<[email protected]>---
I'll probably be going after
__exitafter this one, but it makes sense to split them up, since the hotplug annotation removal looks uncontroversial, whereas__exitand discard section removal might produce more robust debate. I also think doing the hotplug removal gives us 90% of the benefits and removes 90% of the section mismatch problems.
Quoted 6 lines
Quoted 2 lines
Since hotplug is so fundamental nowadays the value no longer outweighs the pain/cost to me, so
Granted for normal hotplug.
But my computer has neither CPU hotplug
cpuhotplug is required for suspend/resume.
Signature · 3 lines
If you want to reach me at my work email, use [email protected] For development, discussion and tips for power savings, visit http://www.lesswatts.org
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 25 lines · Arjan van de Ven
Quoted 22 lines · On Thu, 31 Jan 2008 18:21:42 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 21 lines · Arjan van de Ven
Quoted 16 lines · On Thu, 31 Jan 2008 09:57:31 -0600 James Bottomley…
No-one seems to see much value in these, and they cause about 90% of our problems with __init/__exit markers, so simply eliminate them. Rather than run over the whole tree removing them, this patch #defines them to be nops.
Signed-off-by: James Bottomley
<[email protected]>---
I'll probably be going after
__exitafter this one, but it makes sense to split them up, since the hotplug annotation removal looks uncontroversial, whereas__exitand discard section removal might produce more robust debate. I also think doing the hotplug removal gives us 90% of the benefits and removes 90% of the section mismatch problems.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Since hotplug is so fundamental nowadays the value no longer outweighs the pain/cost to me, so
Granted for normal hotplug.
But my computer has neither CPU hotplug
cpuhotplug is required for suspend/resume.
Not on UP computers.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: [PATCH] kill hotplug init/exit section annotations
Quoted 3 lines · Adrian Bunk
Quoted 1 line
cpuhotplug is required for suspend/resume.
Not on UP computers.
those are less and less common now, most modern laptops are dual core
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 7 lines · Chris Wedgwood
Quoted 3 lines · Adrian Bunk
Quoted 1 line
cpuhotplug is required for suspend/resume.
Not on UP computers.
those are less and less common now, most modern laptops are dual core
Who was talking about laptops?
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: [PATCH] kill hotplug init/exit section annotations
Quoted 1 line · Adrian Bunk
Who was talking about laptops?
If laptops are mostly MP these days, then 'desktops' and 'servers' certainly are --- so pretty much everyone needs CPU hotplug.
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 5 lines · Chris Wedgwood
Quoted 1 line · Adrian Bunk
Who was talking about laptops?
If laptops are mostly MP these days, then 'desktops' and 'servers' certainly are --- so pretty much everyone needs CPU hotplug.
<irony>
Thank you for giving an exhaustive list of classes of machines Linux runs on! </irony>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] kill hotplug init/exit section annotations
In reply to Adrian BunkQuoted 4 lines · On Thu, 31 Jan 2008 19:14:36 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 1 line
cpuhotplug is required for suspend/resume.
Not on UP computers.
great! someone who still has one of those and uses a kernel without it. Can you look at your system.map and see how many kilobytes you've gained? Eg how many kilobytes are in these sections exactly?
(but also subtract any cost due to page aligning this stuff ;-)
Quoted 3 lines
cu
Adrian
Signature · 3 lines
If you want to reach me at my work email, use [email protected] For development, discussion and tips for power savings, visit http://www.lesswatts.org
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 10 lines · Arjan van de Ven
Quoted 4 lines · On Thu, 31 Jan 2008 19:14:36 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 1 line
cpuhotplug is required for suspend/resume.
Not on UP computers.
great! someone who still has one of those and uses a kernel without it. Can you look at your system.map and see how many kilobytes you've gained? Eg how many kilobytes are in these sections exactly?
I have one. A Atmel AT91 board equipped with an 9263.
So lets take a look at the defconfig build for the evaluation board.
o-arm/vmlinux.o: file format elf32-littlearm
0 .text 001cdefc 00000000 00000000 00000400 2**10 2 .init.text 000165e8 00000000 00000000 001ce6c0 2**5 26 .init.data 000032ec 00000000 00000000 002578cc 2**2
---
4 .devinit.text 00001558 00000000 00000000 001e5270 2**2 9 .exit.text 00000bc8 00000000 00000000 001e8d2c 2**2 10 .cpuinit.text 00000924 00000000 00000000 001e98f4 2**2 11 .meminit.text 000004cc 00000000 00000000 001ea218 2**2 12 .devexit.text 00000160 00000000 00000000 001ea6e4 2**2 38 .cpuinit.data 00000040 00000000 00000000 0025afc0 2**2 39 .meminit.data 0000000c 00000000 00000000 0025b000 2**2
__devinit alone gives a net win of 5464 bytes.
That is only ~3% of total .text size but this is non-swapable memory where everything is worth it.
And the configuration selected is by no means optimal with respect to minimal size.
Sam
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 32 lines · On Thu, 31 Jan 2008 19:34:25 +0100 Sam Ravnborg <[email protected]> wrote:
Quoted 10 lines · Arjan van de Ven
Quoted 4 lines · On Thu, 31 Jan 2008 19:14:36 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 1 line
cpuhotplug is required for suspend/resume.
Not on UP computers.
great! someone who still has one of those and uses a kernel without it. Can you look at your system.map and see how many kilobytes you've gained? Eg how many kilobytes are in these sections exactly?
I have one. A Atmel AT91 board equipped with an 9263.
So lets take a look at the defconfig build for the evaluation board.
o-arm/vmlinux.o: file format elf32-littlearm0 .text 001cdefc 00000000 00000000 00000400 2**10 2 .init.text 000165e8 00000000 00000000 001ce6c0 2**5 26 .init.data 000032ec 00000000 00000000 002578cc 2**2---
4 .devinit.text 00001558 00000000 00000000 001e5270 2**2 9 .exit.text 00000bc8 00000000 00000000 001e8d2c 2**2 10 .cpuinit.text 00000924 00000000 00000000 001e98f4 2**2 11 .meminit.text 000004cc 00000000 00000000 001ea218 2**2 12 .devexit.text 00000160 00000000 00000000 001ea6e4 2**2 38 .cpuinit.data 00000040 00000000 00000000 0025afc0 2**2 39 .meminit.data 0000000c 00000000 00000000 0025b000 2**2
Quoted 3 lines
__devinitalone gives a net win of 5464 bytes.
That is only ~3% of total .text size but this is non-swapable memory where everything is worth it.
now how much of this is lost again because you have to round the stuff to pagesize?
Re: [PATCH] kill hotplug init/exit section annotations
Quoted 35 lines · Arjan van de Ven
Quoted 32 lines · On Thu, 31 Jan 2008 19:34:25 +0100 Sam Ravnborg <[email protected]> wrote:
Quoted 10 lines · Arjan van de Ven
Quoted 4 lines · On Thu, 31 Jan 2008 19:14:36 +0200 Adrian Bunk <[email protected]> wrote:
Quoted 1 line
cpuhotplug is required for suspend/resume.
Not on UP computers.
great! someone who still has one of those and uses a kernel without it. Can you look at your system.map and see how many kilobytes you've gained? Eg how many kilobytes are in these sections exactly?
I have one. A Atmel AT91 board equipped with an 9263.
So lets take a look at the defconfig build for the evaluation board.
o-arm/vmlinux.o: file format elf32-littlearm0 .text 001cdefc 00000000 00000000 00000400 2**10 2 .init.text 000165e8 00000000 00000000 001ce6c0 2**5 26 .init.data 000032ec 00000000 00000000 002578cc 2**2---
4 .devinit.text 00001558 00000000 00000000 001e5270 2**2 9 .exit.text 00000bc8 00000000 00000000 001e8d2c 2**2 10 .cpuinit.text 00000924 00000000 00000000 001e98f4 2**2 11 .meminit.text 000004cc 00000000 00000000 001ea218 2**2 12 .devexit.text 00000160 00000000 00000000 001ea6e4 2**2 38 .cpuinit.data 00000040 00000000 00000000 0025afc0 2**2 39 .meminit.data 0000000c 00000000 00000000 0025b000 2**2
Quoted 5 lines
Quoted 3 lines
__devinitalone gives a net win of 5464 bytes.
That is only ~3% of total .text size but this is non-swapable memory where everything is worth it.now how much of this is lost again because you have to round the stuff to pagesize?
Lets take a look in the ARM vmlinux.lds.S file:
.text.head : {
_stext = .;
_sinittext = .;
*(.text.head)
}
.init : { /* Init code and data */
INIT_TEXT
_einittext = .;
__proc_info_begin = .;
*(.proc.info.init)
__proc_info_end = .;
__arch_info_begin = .;
*(.arch.info.init)
__arch_info_end = .;
__tagtable_begin = .;
*(.taglist.init)
__tagtable_end = .;
. = ALIGN(16);
__setup_start = .;
*(.init.setup)
__setup_end = .;
__early_begin = .;
*(.early_param.init)
__early_end = .;
__initcall_start = .;
INITCALLS
__initcall_end = .;
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
__security_initcall_start = .;
*(.security_initcall.init)
__security_initcall_end = .;
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(32);
__initramfs_start = .;
usr/built-in.o(.init.ramfs)
__initramfs_end = .;
#endif
. = ALIGN(4096);
__per_cpu_start = .;
*(.data.percpu)
*(.data.percpu.shared_aligned)
__per_cpu_end = .;
#ifndef CONFIG_XIP_KERNEL
__init_begin = _stext;
INIT_DATA
. = ALIGN(4096);
__init_end = .;Everything between _stext and __init_end are freed.
And we have two PAGESIZE alignmnets here - one for the percpu stuff and the other to align the full area that can be freed. So there is no special alignment for the __devinit stuff.
And there is no percpu data on ARM so that area is empty. So it is one or two pages extra that are freed up.
Sam
Quoted 15 lines · James Bottomley
Quoted 4 lines · Adrian Bunk
This patch fixes the following section mismatches:
<-- snip -->
Quoted 8 lines
...
WARNING: drivers/scsi/qlogicpti.o(.devexit.text+0x8): Section mismatch in reference from the functionqpti_sbus_remove()to the function .init.text:qpti_chain_del()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x56c): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_regs()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x580): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_register_irq()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x594): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_get_scsi_id()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x5b8): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_map_queues()
WARNING: drivers/scsi/qlogicpti.o(.devinit.text+0x780): Section mismatch in reference from the functionqpti_sbus_probe()to the function .init.text:qpti_chain_add()
...
Quoted 8 lines
OK, look, this is really getting out of hand.
__initis possibly justifiable with a few hundred k savings on boot.__devinitand the rest are surely killable on the grounds they provide little benefit for all the pain they cause.all
__exitseems to do is set us up for unreferenced pointers in discarded sections, so could we kill that too?
When you are on x86 what you see as "Freeing unused kernel memory: " at the end of booting contains both __init and __exit code.
Quoted 1 line
James
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed