Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Fri, 2007-09-07 at 18:30 +0100, Denys Vlasenko wrote: > On Friday 07 September 2007 17:31, Daniel Walker wrote: > > On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote: > > > A bit extended version: > > > > > > In the process in making it work I saw ~10% vmlinux size reductions > > > (which basically matches what Marcelo says) when I wasn't retaining > > > sections needed for EXPORT_SYMBOLs, but module loading didn't work. > > > > > > Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs > > > are never discarded. This was just one of many fixes until kernel > > > started to actually boot and work. > > > > > > I did that before I posted patches to lkml. > > > IOW: posted patches are not broken versus module loading. > > > > Ok, this is more like the explanation I was looking for.. > > > > During this thread you seemed to indicate the patches you release > > reduced the kernel ~10% , but now your saying that was pre-release , > > right? > > CONFIG_MODULE=n will save ~10% > CONFIG_MODULE=y - ~1% > > Exact figure depends on .config (whether you happen to include > especially "fat" code or not). > > I want to explain a bit where I am coming from. I am working on busybox, > and last release made busybox smaller by "whopping" 2%. This is the result > of a hundred or so of small code and data shrinks. > > It basically means that I am close to the point of diminishing returns > trying to make busybox smaller, and memory wastage on the running > embedded system is now elsewhere - including kernel. I think this type of pruning is a good thing, you could even say the biggest bit of low hanging fruit in terms of size reduction. I think your patches are good, but need some work. There are still some changes that could reduce the kernel further (i.e. when modules are used) .. So I'm not trying to discourage you, but you set off some alarms with me early in the thread.. Which caused this to drag out.. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Fri, 2007-09-07 at 19:24 +0200, Sam Ravnborg wrote: > Hi Daniel. > > > > I did that before I posted patches to lkml. > > > IOW: posted patches are not broken versus module loading. > > > > Ok, this is more like the explanation I was looking for.. > > > > During this thread you seemed to indicate the patches you release > > reduced the kernel ~10% , but now your saying that was pre-release , > > right? > > What are you after here? > > If you read the inital post you see the actual savings and you also > can read that it works wiht modules. The precentage can be calculated > from these numbers if you are interested. Right, but he contradicted that during the course of this thread.. Which is why I'm asking about it.. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Friday 07 September 2007 17:31, Daniel Walker wrote: > On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote: > > A bit extended version: > > > > In the process in making it work I saw ~10% vmlinux size reductions > > (which basically matches what Marcelo says) when I wasn't retaining > > sections needed for EXPORT_SYMBOLs, but module loading didn't work. > > > > Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs > > are never discarded. This was just one of many fixes until kernel > > started to actually boot and work. > > > > I did that before I posted patches to lkml. > > IOW: posted patches are not broken versus module loading. > > Ok, this is more like the explanation I was looking for.. > > During this thread you seemed to indicate the patches you release > reduced the kernel ~10% , but now your saying that was pre-release , > right? CONFIG_MODULE=n will save ~10% CONFIG_MODULE=y - ~1% Exact figure depends on .config (whether you happen to include especially "fat" code or not). I want to explain a bit where I am coming from. I am working on busybox, and last release made busybox smaller by "whopping" 2%. This is the result of a hundred or so of small code and data shrinks. It basically means that I am close to the point of diminishing returns trying to make busybox smaller, and memory wastage on the running embedded system is now elsewhere - including kernel. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
Hi Daniel. > > I did that before I posted patches to lkml. > > IOW: posted patches are not broken versus module loading. > > Ok, this is more like the explanation I was looking for.. > > During this thread you seemed to indicate the patches you release > reduced the kernel ~10% , but now your saying that was pre-release , > right? What are you after here? If you read the inital post you see the actual savings and you also can read that it works wiht modules. The precentage can be calculated from these numbers if you are interested. As explained later this patch does NOT remove exported symbols since they may be used by modules that are not included in the actual build. And the patch works for x86_64. So I'm a bit puzzeled what you are trying to bring forward here. And please read carefully the initial posting again... Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote: > A bit extended version: > > In the process in making it work I saw ~10% vmlinux size reductions > (which basically matches what Marcelo says) when I wasn't retaining > sections needed for EXPORT_SYMBOLs, but module loading didn't work. > > Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs > are never discarded. This was just one of many fixes until kernel > started to actually boot and work. > > I did that before I posted patches to lkml. > IOW: posted patches are not broken versus module loading. Ok, this is more like the explanation I was looking for.. During this thread you seemed to indicate the patches you release reduced the kernel ~10% , but now your saying that was pre-release , right? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote: A bit extended version: In the process in making it work I saw ~10% vmlinux size reductions (which basically matches what Marcelo says) when I wasn't retaining sections needed for EXPORT_SYMBOLs, but module loading didn't work. Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs are never discarded. This was just one of many fixes until kernel started to actually boot and work. I did that before I posted patches to lkml. IOW: posted patches are not broken versus module loading. Ok, this is more like the explanation I was looking for.. During this thread you seemed to indicate the patches you release reduced the kernel ~10% , but now your saying that was pre-release , right? Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
Hi Daniel. I did that before I posted patches to lkml. IOW: posted patches are not broken versus module loading. Ok, this is more like the explanation I was looking for.. During this thread you seemed to indicate the patches you release reduced the kernel ~10% , but now your saying that was pre-release , right? What are you after here? If you read the inital post you see the actual savings and you also can read that it works wiht modules. The precentage can be calculated from these numbers if you are interested. As explained later this patch does NOT remove exported symbols since they may be used by modules that are not included in the actual build. And the patch works for x86_64. So I'm a bit puzzeled what you are trying to bring forward here. And please read carefully the initial posting again... Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Friday 07 September 2007 17:31, Daniel Walker wrote: On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote: A bit extended version: In the process in making it work I saw ~10% vmlinux size reductions (which basically matches what Marcelo says) when I wasn't retaining sections needed for EXPORT_SYMBOLs, but module loading didn't work. Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs are never discarded. This was just one of many fixes until kernel started to actually boot and work. I did that before I posted patches to lkml. IOW: posted patches are not broken versus module loading. Ok, this is more like the explanation I was looking for.. During this thread you seemed to indicate the patches you release reduced the kernel ~10% , but now your saying that was pre-release , right? CONFIG_MODULE=n will save ~10% CONFIG_MODULE=y - ~1% Exact figure depends on .config (whether you happen to include especially fat code or not). I want to explain a bit where I am coming from. I am working on busybox, and last release made busybox smaller by whopping 2%. This is the result of a hundred or so of small code and data shrinks. It basically means that I am close to the point of diminishing returns trying to make busybox smaller, and memory wastage on the running embedded system is now elsewhere - including kernel. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Fri, 2007-09-07 at 19:24 +0200, Sam Ravnborg wrote: Hi Daniel. I did that before I posted patches to lkml. IOW: posted patches are not broken versus module loading. Ok, this is more like the explanation I was looking for.. During this thread you seemed to indicate the patches you release reduced the kernel ~10% , but now your saying that was pre-release , right? What are you after here? If you read the inital post you see the actual savings and you also can read that it works wiht modules. The precentage can be calculated from these numbers if you are interested. Right, but he contradicted that during the course of this thread.. Which is why I'm asking about it.. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Fri, 2007-09-07 at 18:30 +0100, Denys Vlasenko wrote: On Friday 07 September 2007 17:31, Daniel Walker wrote: On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote: A bit extended version: In the process in making it work I saw ~10% vmlinux size reductions (which basically matches what Marcelo says) when I wasn't retaining sections needed for EXPORT_SYMBOLs, but module loading didn't work. Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs are never discarded. This was just one of many fixes until kernel started to actually boot and work. I did that before I posted patches to lkml. IOW: posted patches are not broken versus module loading. Ok, this is more like the explanation I was looking for.. During this thread you seemed to indicate the patches you release reduced the kernel ~10% , but now your saying that was pre-release , right? CONFIG_MODULE=n will save ~10% CONFIG_MODULE=y - ~1% Exact figure depends on .config (whether you happen to include especially fat code or not). I want to explain a bit where I am coming from. I am working on busybox, and last release made busybox smaller by whopping 2%. This is the result of a hundred or so of small code and data shrinks. It basically means that I am close to the point of diminishing returns trying to make busybox smaller, and memory wastage on the running embedded system is now elsewhere - including kernel. I think this type of pruning is a good thing, you could even say the biggest bit of low hanging fruit in terms of size reduction. I think your patches are good, but need some work. There are still some changes that could reduce the kernel further (i.e. when modules are used) .. So I'm not trying to discourage you, but you set off some alarms with me early in the thread.. Which caused this to drag out.. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Fri, Sep 07, 2007 at 12:01:56AM +0200, Oleg Verych wrote: >... > > And code review and Denys' patch have cumulative effects since his patch > > results in improvements that can't be resonably done other than at > > the ld and/or gcc level. > > I was talking about introducing such things in development process. > Current kconfig may be not flexible, it must not lead to further problems > and silver-bullet solutions. >... The patches in this thread are not in any way related to any problems with kconfig... cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
* Thu, 6 Sep 2007 23:19:55 +0200 > > On Thu, Sep 06, 2007 at 11:16:15PM +0200, Oleg Verych wrote: >> * Thu, 6 Sep 2007 22:39:31 +0200 >> >> [] >> >> > His patch improves the build process. >> >> >> >> I would like to know timing, btw. Size, especially shown 1%, doesn't >> >> matter if link time increased dramatically. `Allyes' config, when i *if* >> >> had fast and rammish machine was terrible thing (last winter). If 32 >> >> cores/cpus is will of author, then i'm even more suspicious. >> > >> > For non-developers size and speed of the kernel matter much more than >> > compile time. >> >> I'm talking about benefits for the process (developers, testers) and >> the result (end users, dogs eating own food :). > > Your claim was that link time was more important than code size, and > that claim is in many cases wrong. I just noted, that maybe (*if*) build/link time have been affected. There was an example of size reduction, why not to have timings also? I guess, developer can spend time tuning written driver with that option/patch. But what you will write in the help message for testers/users? In this case build time is important obviously. Runtime isn't affected at all, except, maybe, ~1% increase in bzImage unzipping. Whatever. >> > When you go towards embedded systems with limited resources a 1% size >> > decrease would often be worth it even if it would (hypothetically) >> > increase the compile time by a factor of 10. >> >>textdata bss dec hex filename >>5159478 1005139 406784 6571401 644589 linux-2.6.23-rc4.org/vmlinux >>5131822 996090 401439 6529351 63a147 linux-2.6.23-rc4.gc/vmlinux >> >> Are this numbers show embedded target? I think no. Also time factor of >> *10* can be spent more productively reviewing actual code of parts, that >> are going to be embedded, no? > > First of all, please lookup the word "hypothetically" in a dictionary. Do you mean hand-waving? Whatever. > And code review and Denys' patch have cumulative effects since his patch > results in improvements that can't be resonably done other than at > the ld and/or gcc level. I was talking about introducing such things in development process. Current kconfig may be not flexible, it must not lead to further problems and silver-bullet solutions. >> [] >> >> > There's nothing that requires treatment. >> >> >> >> [Help for] The developers/contributors of those drivers, no? >> >>... >> > >> > They did everything right. >> > >> > You should better try to understand the problem first before behaving as >> > if you knew everything better than everyone else... >> >> OK, thank you very much. Now, describe what problem you are talking >> about, please. I see non. > > If you don't understand what the patches in this thread are about then > you shouldn't have started commenting on this thread... Not first time i see, what i should do. Thank you very much, Adrian! You know better, what i know. Great. Then say from the beginning that you're not interested in reviewing and view-exchanging process, you know better, what i should do. Thus, i will not waste my time explaining anything. Whatever. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 11:16:15PM +0200, Oleg Verych wrote: > * Thu, 6 Sep 2007 22:39:31 +0200 > > [] > >> > His patch improves the build process. > >> > >> I would like to know timing, btw. Size, especially shown 1%, doesn't > >> matter if link time increased dramatically. `Allyes' config, when i > >> had fast and rammish machine was terrible thing (last winter). If 32 > >> cores/cpus is will of author, then i'm even more suspicious. > > > > For non-developers size and speed of the kernel matter much more than > > compile time. > > I'm talking about benefits for the process (developers, testers) and > the result (end users, dogs eating own food :). Your claim was that link time was more important than code size, and that claim is in many cases wrong. > > When you go towards embedded systems with limited resources a 1% size > > decrease would often be worth it even if it would (hypothetically) > > increase the compile time by a factor of 10. > >textdata bss dec hex filename >5159478 1005139 406784 6571401 644589 linux-2.6.23-rc4.org/vmlinux >5131822 996090 401439 6529351 63a147 linux-2.6.23-rc4.gc/vmlinux > > Are this numbers show embedded target? I think no. Also time factor of > *10* can be spent more productively reviewing actual code of parts, that > are going to be embedded, no? First of all, please lookup the word "hypothetically" in a dictionary. And code review and Denys' patch have cumulative effects since his patch results in improvements that can't be resonably done other than at the ld and/or gcc level. > [] > >> > There's nothing that requires treatment. > >> > >> [Help for] The developers/contributors of those drivers, no? > >>... > > > > They did everything right. > > > > You should better try to understand the problem first before behaving as > > if you knew everything better than everyone else... > > OK, thank you very much. Now, describe what problem you are talking > about, please. I see non. If you don't understand what the patches in this thread are about then you shouldn't have started commenting on this thread... cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
* Thu, 6 Sep 2007 22:39:31 +0200 [] >> > His patch improves the build process. >> >> I would like to know timing, btw. Size, especially shown 1%, doesn't >> matter if link time increased dramatically. `Allyes' config, when i >> had fast and rammish machine was terrible thing (last winter). If 32 >> cores/cpus is will of author, then i'm even more suspicious. > > For non-developers size and speed of the kernel matter much more than > compile time. I'm talking about benefits for the process (developers, testers) and the result (end users, dogs eating own food :). > When you go towards embedded systems with limited resources a 1% size > decrease would often be worth it even if it would (hypothetically) > increase the compile time by a factor of 10. textdata bss dec hex filename 5159478 1005139 406784 6571401 644589 linux-2.6.23-rc4.org/vmlinux 5131822 996090 401439 6529351 63a147 linux-2.6.23-rc4.gc/vmlinux Are this numbers show embedded target? I think no. Also time factor of *10* can be spent more productively reviewing actual code of parts, that are going to be embedded, no? [] >> > There's nothing that requires treatment. >> >> [Help for] The developers/contributors of those drivers, no? >>... > > They did everything right. > > You should better try to understand the problem first before behaving as > if you knew everything better than everyone else... OK, thank you very much. Now, describe what problem you are talking about, please. I see non. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 10:43:49PM +0200, Oleg Verych wrote: > On Thu, Sep 06, 2007 at 02:21:43PM +0200, Adrian Bunk wrote: > [] > > > You've did a tool. Documenting this tool to have it available for > > > testers/janitors/maintainers is a better way, than to have all that > > > opinions/problems with merging-to-mainline. > > > > There is no problem with his patch. > > > > His patch improves the build process. > > I would like to know timing, btw. Size, especially shown 1%, doesn't > matter if link time increased dramatically. `Allyes' config, when i > had fast and rammish machine was terrible thing (last winter). If 32 > cores/cpus is will of author, then i'm even more suspicious. For non-developers size and speed of the kernel matter much more than compile time. When you go towards embedded systems with limited resources a 1% size decrease would often be worth it even if it would (hypothetically) increase the compile time by a factor of 10. >... > > > > I don't understand why you are opposed to toolchain helping > > > > humans to get optimized result. But it's fine with me. > > > > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. > > > > > > That's why. It's treating symptoms, isn't it? > > > > There's nothing that requires treatment. > > [Help for] The developers/contributors of those drivers, no? >... They did everything right. You should better try to understand the problem first before behaving as if you knew everything better than everyone else... cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 02:21:43PM +0200, Adrian Bunk wrote: [] > > You've did a tool. Documenting this tool to have it available for > > testers/janitors/maintainers is a better way, than to have all that > > opinions/problems with merging-to-mainline. > > There is no problem with his patch. > > His patch improves the build process. I would like to know timing, btw. Size, especially shown 1%, doesn't matter if link time increased dramatically. `Allyes' config, when i had fast and rammish machine was terrible thing (last winter). If 32 cores/cpus is will of author, then i'm even more suspicious. > And there's no reason to hide this from the users. Patch? Did i said patch? Ah, patch. Yes -- hide it, because it against LKML's rules. I can provide ftp for such things, easily. I said tool _and_ documentation. Because if developers don't know about `static' code or _data_ and cann't find out that, then small description is more than welcome, i think. But, tool. Hide it also, becasue it's kind of thing to be shamed of (: == untested, for demonstation only == SED_REM=' /\.text\./s|\.text\.|.text_|g; /\.data\./s|\.data\.|.data_|g; /\.bss\.p/s|\.bss\.p|.bss_p|g; # for .bss.page_aligned only ' for place in linux/arch/* linux/kernel linux/include/asm-* do case $place *cris) ADDON='/\.text\.__/n;' ;; *powerpc) ADDON='/\.data\.rel/n;' ;; *parisc)ADDON='/\.data\.vm[p0]/n;' ;; *frv) ADDON='/\.bss\.stack/n;';; esac sed -i -e "$ADDON$SED_REM" `find $place -type f` done done == == [] > > > I don't understand why you are opposed to toolchain helping > > > humans to get optimized result. But it's fine with me. > > > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. > > > > That's why. It's treating symptoms, isn't it? > > There's nothing that requires treatment. [Help for] The developers/contributors of those drivers, no? > It's a matter of fact that the kernel takes advantages from some > features of GNU binutils and GNU gcc that might not be available > in other versions of these tools. > > Whether you like it or not - that's not going to change. I don't like fast, one-sided solutions. > But don't continue arguing about something where you won't win with > words - it's open source, so you can always create a fork of the Linux > kernel that builds with whatever toolchain you want. I just want to have review process to be real not only in C hacking. > The only way you could convince other people from your point of view > would be if your forked version of the kernel would contain advantages > that convince many users to use your kernel rather than Linus' one. > > cu > Adrian > > -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thursday 06 September 2007 16:13, Daniel Walker wrote: > On Thu, 2007-09-06 at 11:57 +0100, Denys Vlasenko wrote: > > On Wednesday 05 September 2007 20:46, Daniel Walker wrote: > > > On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: > > > > > > > What does "it" stand for in this sentence? > > > > > > "it" is your patches, and I think we got to bottom of it .. "it" (i.e. > > > your patches) don't actually work with modules, which is what you > > > originally contended .. > > > > Kernel builds, loads and runs with my patches, and modules load just fine. > > Ok, so I guess we're not clear on this point .. In your last email you > said that module exports might get removed? Is that what you intended to > say or not? I said this: On Wednesday 05 September 2007 20:14, Denys Vlasenko wrote: > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > It works with CONFIG_MODULES. > > > > Really? Take a look at this version, > > > > http://lkml.org/lkml/2006/6/4/169 > > > > Marcello had to implement a two pass build to add back symbol used in > > modules which got removed from the main kernel.. You don't appear to do > > that. Marcelo also claims better size reduction than you. > > This will discard EXPORT_SYMBOLs potentially used by > out-of-tree modules. > > I also saw ~10% size reductions, but then at run-time test modules > failed to load, they didn't find needed symbols. A bit extended version: In the process in making it work I saw ~10% vmlinux size reductions (which basically matches what Marcelo says) when I wasn't retaining sections needed for EXPORT_SYMBOLs, but module loading didn't work. Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs are never discarded. This was just one of many fixes until kernel started to actually boot and work. I did that before I posted patches to lkml. IOW: posted patches are not broken versus module loading. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, 2007-09-06 at 11:57 +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 20:46, Daniel Walker wrote: > > On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: > > > > > What does "it" stand for in this sentence? > > > > "it" is your patches, and I think we got to bottom of it .. "it" (i.e. > > your patches) don't actually work with modules, which is what you > > originally contended .. > > Kernel builds, loads and runs with my patches, and modules load just fine. Ok, so I guess we're not clear on this point .. In your last email you said that module exports might get removed? Is that what you intended to say or not? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thursday 06 September 2007 12:40, Oleg Verych wrote: > On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote: > > We already do it, but we don't have enough developers to audit > > every driver for every possible combination of config options. > > As a result, there always be some amount of unused functions and data. > > Using --gc-sections will discard that. > > You've did a tool. Documenting this tool to have it available for > testers/janitors/maintainers is a better way, than to have all that > opinions/problems with merging-to-mainline. > > > > than to adopt yet another GNU/Luxury. > > > > Actually, this is how linkers should have worked long ago. > > Borland's Turbo Pascal was doing it ten+ years ago. > > > > I don't understand why you are opposed to toolchain helping > > humans to get optimized result. But it's fine with me. > > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. > > That's why. It's treating symptoms, isn't it? If I understand you correctly, you seem to think that this work of identifying every piece of code which can end up unused under specific combination of CONFIGs, and #ifdef'ing it out, should be done by people, not machines. I disagree. Allyesconfig kernel has ~1700 unused functions/data objects, and it is only *one* of possible .configs. There is more than 2900 CONFIG options in kernel, giving you about 3^2000 possible permutations. If you find it interesting to work on making them to not have unused functions, more power to you, and good luck convincing people to accept tons of additional #ifdefs. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 01:40:44PM +0200, Oleg Verych wrote: > On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote: > [] > > > Give me example, please, why function must be non static if not used. > > > > Where do you see I'm saying that they must be non-static? > > I'm all for marking functions static. I just did it for aic7xxx. > > > > > If usage requires kconfig tuning, then this is a better way to go, > > > > We already do it, but we don't have enough developers to audit > > every driver for every possible combination of config options. > > As a result, there always be some amount of unused functions and data. > > Using --gc-sections will discard that. > > You've did a tool. Documenting this tool to have it available for > testers/janitors/maintainers is a better way, than to have all that > opinions/problems with merging-to-mainline. There is no problem with his patch. His patch improves the build process. And there's no reason to hide this from the users. > > > than to adopt yet another GNU/Luxury. > > > > Actually, this is how linkers should have worked long ago. > > Borland's Turbo Pascal was doing it ten+ years ago. > > > > I don't understand why you are opposed to toolchain helping > > humans to get optimized result. But it's fine with me. > > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. > > That's why. It's treating symptoms, isn't it? There's nothing that requires treatment. It's a matter of fact that the kernel takes advantages from some features of GNU binutils and GNU gcc that might not be available in other versions of these tools. Whether you like it or not - that's not going to change. But don't continue arguing about something where you won't win with words - it's open source, so you can always create a fork of the Linux kernel that builds with whatever toolchain you want. The only way you could convince other people from your point of view would be if your forked version of the kernel would contain advantages that convince many users to use your kernel rather than Linus' one. cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote: [] > > Give me example, please, why function must be non static if not used. > > Where do you see I'm saying that they must be non-static? > I'm all for marking functions static. I just did it for aic7xxx. > > > If usage requires kconfig tuning, then this is a better way to go, > > We already do it, but we don't have enough developers to audit > every driver for every possible combination of config options. > As a result, there always be some amount of unused functions and data. > Using --gc-sections will discard that. You've did a tool. Documenting this tool to have it available for testers/janitors/maintainers is a better way, than to have all that opinions/problems with merging-to-mainline. > > than to adopt yet another GNU/Luxury. > > Actually, this is how linkers should have worked long ago. > Borland's Turbo Pascal was doing it ten+ years ago. > > I don't understand why you are opposed to toolchain helping > humans to get optimized result. But it's fine with me. > I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. That's why. It's treating symptoms, isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 20:46, Daniel Walker wrote: > On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: > > > What does "it" stand for in this sentence? > > "it" is your patches, and I think we got to bottom of it .. "it" (i.e. > your patches) don't actually work with modules, which is what you > originally contended .. Kernel builds, loads and runs with my patches, and modules load just fine. > > My patch was tested to work in my limited testing, > > but it is very conservative. > > > > I can't talk for Marcelo, but his patch probably worked too, > > it just didn't guarantee that you can install kernel, and > > then compile and load external module. Wel, it will compile, > > but maybe will fail to load. > > At least you should modify your Kconfig changes so that you don't allow > people to select your new option unless they have CONFIG_MODULES off.. You seem to have interesting definition of "desn't work". -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 21:34, Oleg Verych wrote: > > > > Build system: section garbage collection for vmlinux > > > > > > Maybe this is just a test suit to get finish with `make XYZ static`? > > > > They are vaguely connected in a sense that unused function which is > > not marked static doesn't generate gcc warning, but will be discarded > > by --gc-sections. "make XYZ static" also tends to find them - you make > > function static, you recompile the file, and gcc informs you that > > the function is not used at all! > > > > This happened to me when I did aic7xxx patches. > > > > You may yse --print-gc-sections to see the list of discarded sections. > > Anyway, this is gccism/binutilizm. That about other possible/future > options? > > Give me example, please, why function must be non static if not used. Where do you see I'm saying that they must be non-static? I'm all for marking functions static. I just did it for aic7xxx. > If usage requires kconfig tuning, then this is a better way to go, We already do it, but we don't have enough developers to audit every driver for every possible combination of config options. As a result, there always be some amount of unused functions and data. Using --gc-sections will discard that. > than to adopt yet another GNU/Luxury. Actually, this is how linkers should have worked long ago. Borland's Turbo Pascal was doing it ten+ years ago. I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 21:34, Oleg Verych wrote: Build system: section garbage collection for vmlinux Maybe this is just a test suit to get finish with `make XYZ static`? They are vaguely connected in a sense that unused function which is not marked static doesn't generate gcc warning, but will be discarded by --gc-sections. make XYZ static also tends to find them - you make function static, you recompile the file, and gcc informs you that the function is not used at all! This happened to me when I did aic7xxx patches. You may yse --print-gc-sections to see the list of discarded sections. Anyway, this is gccism/binutilizm. That about other possible/future options? Give me example, please, why function must be non static if not used. Where do you see I'm saying that they must be non-static? I'm all for marking functions static. I just did it for aic7xxx. If usage requires kconfig tuning, then this is a better way to go, We already do it, but we don't have enough developers to audit every driver for every possible combination of config options. As a result, there always be some amount of unused functions and data. Using --gc-sections will discard that. than to adopt yet another GNU/Luxury. Actually, this is how linkers should have worked long ago. Borland's Turbo Pascal was doing it ten+ years ago. I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 20:46, Daniel Walker wrote: On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: What does it stand for in this sentence? it is your patches, and I think we got to bottom of it .. it (i.e. your patches) don't actually work with modules, which is what you originally contended .. Kernel builds, loads and runs with my patches, and modules load just fine. My patch was tested to work in my limited testing, but it is very conservative. I can't talk for Marcelo, but his patch probably worked too, it just didn't guarantee that you can install kernel, and then compile and load external module. Wel, it will compile, but maybe will fail to load. At least you should modify your Kconfig changes so that you don't allow people to select your new option unless they have CONFIG_MODULES off.. You seem to have interesting definition of desn't work. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote: [] Give me example, please, why function must be non static if not used. Where do you see I'm saying that they must be non-static? I'm all for marking functions static. I just did it for aic7xxx. If usage requires kconfig tuning, then this is a better way to go, We already do it, but we don't have enough developers to audit every driver for every possible combination of config options. As a result, there always be some amount of unused functions and data. Using --gc-sections will discard that. You've did a tool. Documenting this tool to have it available for testers/janitors/maintainers is a better way, than to have all that opinions/problems with merging-to-mainline. than to adopt yet another GNU/Luxury. Actually, this is how linkers should have worked long ago. Borland's Turbo Pascal was doing it ten+ years ago. I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. That's why. It's treating symptoms, isn't it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 01:40:44PM +0200, Oleg Verych wrote: On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote: [] Give me example, please, why function must be non static if not used. Where do you see I'm saying that they must be non-static? I'm all for marking functions static. I just did it for aic7xxx. If usage requires kconfig tuning, then this is a better way to go, We already do it, but we don't have enough developers to audit every driver for every possible combination of config options. As a result, there always be some amount of unused functions and data. Using --gc-sections will discard that. You've did a tool. Documenting this tool to have it available for testers/janitors/maintainers is a better way, than to have all that opinions/problems with merging-to-mainline. There is no problem with his patch. His patch improves the build process. And there's no reason to hide this from the users. than to adopt yet another GNU/Luxury. Actually, this is how linkers should have worked long ago. Borland's Turbo Pascal was doing it ten+ years ago. I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. That's why. It's treating symptoms, isn't it? There's nothing that requires treatment. It's a matter of fact that the kernel takes advantages from some features of GNU binutils and GNU gcc that might not be available in other versions of these tools. Whether you like it or not - that's not going to change. But don't continue arguing about something where you won't win with words - it's open source, so you can always create a fork of the Linux kernel that builds with whatever toolchain you want. The only way you could convince other people from your point of view would be if your forked version of the kernel would contain advantages that convince many users to use your kernel rather than Linus' one. cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thursday 06 September 2007 12:40, Oleg Verych wrote: On Thu, Sep 06, 2007 at 11:55:46AM +0100, Denys Vlasenko wrote: We already do it, but we don't have enough developers to audit every driver for every possible combination of config options. As a result, there always be some amount of unused functions and data. Using --gc-sections will discard that. You've did a tool. Documenting this tool to have it available for testers/janitors/maintainers is a better way, than to have all that opinions/problems with merging-to-mainline. than to adopt yet another GNU/Luxury. Actually, this is how linkers should have worked long ago. Borland's Turbo Pascal was doing it ten+ years ago. I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. That's why. It's treating symptoms, isn't it? If I understand you correctly, you seem to think that this work of identifying every piece of code which can end up unused under specific combination of CONFIGs, and #ifdef'ing it out, should be done by people, not machines. I disagree. Allyesconfig kernel has ~1700 unused functions/data objects, and it is only *one* of possible .configs. There is more than 2900 CONFIG options in kernel, giving you about 3^2000 possible permutations. If you find it interesting to work on making them to not have unused functions, more power to you, and good luck convincing people to accept tons of additional #ifdefs. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, 2007-09-06 at 11:57 +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 20:46, Daniel Walker wrote: On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: What does it stand for in this sentence? it is your patches, and I think we got to bottom of it .. it (i.e. your patches) don't actually work with modules, which is what you originally contended .. Kernel builds, loads and runs with my patches, and modules load just fine. Ok, so I guess we're not clear on this point .. In your last email you said that module exports might get removed? Is that what you intended to say or not? Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 02:21:43PM +0200, Adrian Bunk wrote: [] You've did a tool. Documenting this tool to have it available for testers/janitors/maintainers is a better way, than to have all that opinions/problems with merging-to-mainline. There is no problem with his patch. His patch improves the build process. I would like to know timing, btw. Size, especially shown 1%, doesn't matter if link time increased dramatically. `Allyes' config, when i had fast and rammish machine was terrible thing (last winter). If 32 cores/cpus is will of author, then i'm even more suspicious. And there's no reason to hide this from the users. Patch? Did i said patch? Ah, patch. Yes -- hide it, because it against LKML's rules. I can provide ftp for such things, easily. I said tool _and_ documentation. Because if developers don't know about `static' code or _data_ and cann't find out that, then small description is more than welcome, i think. But, tool. Hide it also, becasue it's kind of thing to be shamed of (: == untested, for demonstation only == SED_REM=' /\.text\./s|\.text\.|.text_|g; /\.data\./s|\.data\.|.data_|g; /\.bss\.p/s|\.bss\.p|.bss_p|g; # for .bss.page_aligned only ' for place in linux/arch/* linux/kernel linux/include/asm-* do case $place *cris) ADDON='/\.text\.__/n;' ;; *powerpc) ADDON='/\.data\.rel/n;' ;; *parisc)ADDON='/\.data\.vm[p0]/n;' ;; *frv) ADDON='/\.bss\.stack/n;';; esac sed -i -e $ADDON$SED_REM `find $place -type f` done done == == [] I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. That's why. It's treating symptoms, isn't it? There's nothing that requires treatment. [Help for] The developers/contributors of those drivers, no? It's a matter of fact that the kernel takes advantages from some features of GNU binutils and GNU gcc that might not be available in other versions of these tools. Whether you like it or not - that's not going to change. I don't like fast, one-sided solutions. But don't continue arguing about something where you won't win with words - it's open source, so you can always create a fork of the Linux kernel that builds with whatever toolchain you want. I just want to have review process to be real not only in C hacking. The only way you could convince other people from your point of view would be if your forked version of the kernel would contain advantages that convince many users to use your kernel rather than Linus' one. cu Adrian -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 10:43:49PM +0200, Oleg Verych wrote: On Thu, Sep 06, 2007 at 02:21:43PM +0200, Adrian Bunk wrote: [] You've did a tool. Documenting this tool to have it available for testers/janitors/maintainers is a better way, than to have all that opinions/problems with merging-to-mainline. There is no problem with his patch. His patch improves the build process. I would like to know timing, btw. Size, especially shown 1%, doesn't matter if link time increased dramatically. `Allyes' config, when i had fast and rammish machine was terrible thing (last winter). If 32 cores/cpus is will of author, then i'm even more suspicious. For non-developers size and speed of the kernel matter much more than compile time. When you go towards embedded systems with limited resources a 1% size decrease would often be worth it even if it would (hypothetically) increase the compile time by a factor of 10. ... I don't understand why you are opposed to toolchain helping humans to get optimized result. But it's fine with me. I won't force anyone to select CONFIG_DISCARD_UNUSED_SECTIONS. That's why. It's treating symptoms, isn't it? There's nothing that requires treatment. [Help for] The developers/contributors of those drivers, no? ... They did everything right. You should better try to understand the problem first before behaving as if you knew everything better than everyone else... cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
* Thu, 6 Sep 2007 22:39:31 +0200 [] His patch improves the build process. I would like to know timing, btw. Size, especially shown 1%, doesn't matter if link time increased dramatically. `Allyes' config, when i had fast and rammish machine was terrible thing (last winter). If 32 cores/cpus is will of author, then i'm even more suspicious. For non-developers size and speed of the kernel matter much more than compile time. I'm talking about benefits for the process (developers, testers) and the result (end users, dogs eating own food :). When you go towards embedded systems with limited resources a 1% size decrease would often be worth it even if it would (hypothetically) increase the compile time by a factor of 10. textdata bss dec hex filename 5159478 1005139 406784 6571401 644589 linux-2.6.23-rc4.org/vmlinux 5131822 996090 401439 6529351 63a147 linux-2.6.23-rc4.gc/vmlinux Are this numbers show embedded target? I think no. Also time factor of *10* can be spent more productively reviewing actual code of parts, that are going to be embedded, no? [] There's nothing that requires treatment. [Help for] The developers/contributors of those drivers, no? ... They did everything right. You should better try to understand the problem first before behaving as if you knew everything better than everyone else... OK, thank you very much. Now, describe what problem you are talking about, please. I see non. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Thu, Sep 06, 2007 at 11:16:15PM +0200, Oleg Verych wrote: * Thu, 6 Sep 2007 22:39:31 +0200 [] His patch improves the build process. I would like to know timing, btw. Size, especially shown 1%, doesn't matter if link time increased dramatically. `Allyes' config, when i had fast and rammish machine was terrible thing (last winter). If 32 cores/cpus is will of author, then i'm even more suspicious. For non-developers size and speed of the kernel matter much more than compile time. I'm talking about benefits for the process (developers, testers) and the result (end users, dogs eating own food :). Your claim was that link time was more important than code size, and that claim is in many cases wrong. When you go towards embedded systems with limited resources a 1% size decrease would often be worth it even if it would (hypothetically) increase the compile time by a factor of 10. textdata bss dec hex filename 5159478 1005139 406784 6571401 644589 linux-2.6.23-rc4.org/vmlinux 5131822 996090 401439 6529351 63a147 linux-2.6.23-rc4.gc/vmlinux Are this numbers show embedded target? I think no. Also time factor of *10* can be spent more productively reviewing actual code of parts, that are going to be embedded, no? First of all, please lookup the word hypothetically in a dictionary. And code review and Denys' patch have cumulative effects since his patch results in improvements that can't be resonably done other than at the ld and/or gcc level. [] There's nothing that requires treatment. [Help for] The developers/contributors of those drivers, no? ... They did everything right. You should better try to understand the problem first before behaving as if you knew everything better than everyone else... OK, thank you very much. Now, describe what problem you are talking about, please. I see non. If you don't understand what the patches in this thread are about then you shouldn't have started commenting on this thread... cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Fri, Sep 07, 2007 at 12:01:56AM +0200, Oleg Verych wrote: ... And code review and Denys' patch have cumulative effects since his patch results in improvements that can't be resonably done other than at the ld and/or gcc level. I was talking about introducing such things in development process. Current kconfig may be not flexible, it must not lead to further problems and silver-bullet solutions. ... The patches in this thread are not in any way related to any problems with kconfig... cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 10:34:38PM +0200, Oleg Verych wrote: > On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote: > > On Wednesday 05 September 2007 16:53, Oleg Verych wrote: > > > * Wed, 5 Sep 2007 14:43:21 +0100 > > > * User-Agent: KMail/1.9.1 > > > > > > > > Build system: section garbage collection for vmlinux > > > > > > Maybe this is just a test suit to get finish with `make XYZ static`? > > > > They are vaguely connected in a sense that unused function which is > > not marked static doesn't generate gcc warning, but will be discarded > > by --gc-sections. "make XYZ static" also tends to find them - you make > > function static, you recompile the file, and gcc informs you that > > the function is not used at all! > > > > This happened to me when I did aic7xxx patches. > > > > You may yse --print-gc-sections to see the list of discarded sections. > > Anyway, this is gccism/binutilizm. That about other possible/future > options? The kernel requires GNU gcc and GNU binutils, and if you want to use other tools for building the kernel they have to be sufficiently compatible. > Give me example, please, why function must be non static if not used. s/not used/not used in this kernel configuration/ > If usage requires kconfig tuning, then this is a better way to go, than > to adopt yet another GNU/Luxury. The alternative would be to use an unmaintainable amount of #ifdef's. cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 16:53, Oleg Verych wrote: > > * Wed, 5 Sep 2007 14:43:21 +0100 > > * User-Agent: KMail/1.9.1 > > > > > > Build system: section garbage collection for vmlinux > > > > Maybe this is just a test suit to get finish with `make XYZ static`? > > They are vaguely connected in a sense that unused function which is > not marked static doesn't generate gcc warning, but will be discarded > by --gc-sections. "make XYZ static" also tends to find them - you make > function static, you recompile the file, and gcc informs you that > the function is not used at all! > > This happened to me when I did aic7xxx patches. > > You may yse --print-gc-sections to see the list of discarded sections. Anyway, this is gccism/binutilizm. That about other possible/future options? Give me example, please, why function must be non static if not used. If usage requires kconfig tuning, then this is a better way to go, than to adopt yet another GNU/Luxury. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: > What does "it" stand for in this sentence? "it" is your patches, and I think we got to bottom of it .. "it" (i.e. your patches) don't actually work with modules, which is what you originally contended .. > My patch was tested to work in my limited testing, > but it is very conservative. > > I can't talk for Marcelo, but his patch probably worked too, > it just didn't guarantee that you can install kernel, and > then compile and load external module. Wel, it will compile, > but maybe will fail to load. At least you should modify your Kconfig changes so that you don't allow people to select your new option unless they have CONFIG_MODULES off.. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 20:07, Daniel Walker wrote: > On Wed, 2007-09-05 at 20:14 +0100, Denys Vlasenko wrote: > > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > > > It works with CONFIG_MODULES. > > > > > > Really? Take a look at this version, > > > > > > http://lkml.org/lkml/2006/6/4/169 > > > > > > Marcello had to implement a two pass build to add back symbol used in > > > modules which got removed from the main kernel.. You don't appear to do > > > that. Marcelo also claims better size reduction than you. > > > > This will discard EXPORT_SYMBOLs potentially used by > > out-of-tree modules. > > Right, so it doesn't work with modules.. What does "it" stand for in this sentence? My patch was tested to work in my limited testing, but it is very conservative. I can't talk for Marcelo, but his patch probably worked too, it just didn't guarantee that you can install kernel, and then compile and load external module. Wel, it will compile, but maybe will fail to load. It sounds like *in-tree modules* were loading just fine for Marcelo. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 12:24:04PM -0700, Daniel Walker wrote: > On Wed, 2007-09-05 at 21:31 +0200, Adrian Bunk wrote: > > On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: > > > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > > > > > It works with CONFIG_MODULES. > > > > > > > > Really? Take a look at this version, > > > > > > > > http://lkml.org/lkml/2006/6/4/169 > > > > > > > > Marcello had to implement a two pass build to add back symbol used in > > > > modules which got removed from the main kernel.. You don't appear to do > > > > that. Marcelo also claims better size reduction than you. > > > > > > This will discard EXPORT_SYMBOLs potentially used by > > > out-of-tree modules. > > > > > > I also saw ~10% size reductions, but then at run-time test modules > > > failed to load, they didn't find needed symbols. > > > > > > OTOH if I know that I am not going to be using such modules, > > > then this can be done. Will require another CONFIG_xxx, though. > > > > One point to keep in mind is that the space penalty of CONFIG_MODULES=y > > is so big that CONFIG_MODULES=n is actually the most interesting case > > for small systems that really need small kernels. > > Marcelo's version actual deals with the CONFIG_MODULES=y penalty , which > is interesting to me .. It removes symbols added for CONFIG_MODULES > which actually aren't used .. So CONFIG_MODULES=y is just as interesting > as without (to me at least..). There's still stuff like kernel/module.c or the additional space each used EXPORT_SYMBOL takes that make CONFIG_MODULES=n kernels smaller. But it depends on the use case: If you are aiming for the smallest possible runtime memory usage CONFIG_MODULES=n is the best choice, while for some applications where the bzimage (or similar) size is for some reason limited but the size of the modules doesn't matter the approach you mention might be the best. > Daniel cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 21:31 +0200, Adrian Bunk wrote: > On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: > > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > > > It works with CONFIG_MODULES. > > > > > > Really? Take a look at this version, > > > > > > http://lkml.org/lkml/2006/6/4/169 > > > > > > Marcello had to implement a two pass build to add back symbol used in > > > modules which got removed from the main kernel.. You don't appear to do > > > that. Marcelo also claims better size reduction than you. > > > > This will discard EXPORT_SYMBOLs potentially used by > > out-of-tree modules. > > > > I also saw ~10% size reductions, but then at run-time test modules > > failed to load, they didn't find needed symbols. > > > > OTOH if I know that I am not going to be using such modules, > > then this can be done. Will require another CONFIG_xxx, though. > > One point to keep in mind is that the space penalty of CONFIG_MODULES=y > is so big that CONFIG_MODULES=n is actually the most interesting case > for small systems that really need small kernels. Marcelo's version actual deals with the CONFIG_MODULES=y penalty , which is interesting to me .. It removes symbols added for CONFIG_MODULES which actually aren't used .. So CONFIG_MODULES=y is just as interesting as without (to me at least..). Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > It works with CONFIG_MODULES. > > > > Really? Take a look at this version, > > > > http://lkml.org/lkml/2006/6/4/169 > > > > Marcello had to implement a two pass build to add back symbol used in > > modules which got removed from the main kernel.. You don't appear to do > > that. Marcelo also claims better size reduction than you. > > This will discard EXPORT_SYMBOLs potentially used by > out-of-tree modules. > > I also saw ~10% size reductions, but then at run-time test modules > failed to load, they didn't find needed symbols. > > OTOH if I know that I am not going to be using such modules, > then this can be done. Will require another CONFIG_xxx, though. One point to keep in mind is that the space penalty of CONFIG_MODULES=y is so big that CONFIG_MODULES=n is actually the most interesting case for small systems that really need small kernels. > vda cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 02:43:21PM +0100, Denys Vlasenko wrote: > Build system: section garbage collection for vmlinux > > Newer gcc and binutils can do dead code and data removal > at link time. It is achieved using combination of > -ffunction-sections -fdata-sections options for gcc and > --gc-sections for ld. >... In the long term I'd like us to be able to compile the whole (or at least most of) the kernel with one "-combine -fwhole-program" gcc call which should bring the same positive effect plus enables gcc to do additional optimizations. That's meant as a remark, not against your patch (which is for a lower hanging fruit). > vda cu Adrian -- "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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 20:14 +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > > You version doesn't work with CONFIG_MODULES right? > > > > > > It works with CONFIG_MODULES. > > > > Really? Take a look at this version, > > > > http://lkml.org/lkml/2006/6/4/169 > > > > Marcello had to implement a two pass build to add back symbol used in > > modules which got removed from the main kernel.. You don't appear to do > > that. Marcelo also claims better size reduction than you. > > This will discard EXPORT_SYMBOLs potentially used by > out-of-tree modules. Right , so it doesn't work with modules.. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 19:38, Daniel Walker wrote: > > > You version doesn't work with CONFIG_MODULES right? > > > > It works with CONFIG_MODULES. > > Really? Take a look at this version, > > http://lkml.org/lkml/2006/6/4/169 > > Marcello had to implement a two pass build to add back symbol used in > modules which got removed from the main kernel.. You don't appear to do > that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. I also saw ~10% size reductions, but then at run-time test modules failed to load, they didn't find needed symbols. OTOH if I know that I am not going to be using such modules, then this can be done. Will require another CONFIG_xxx, though. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 19:37 +0100, Denys Vlasenko wrote: > On Wednesday 05 September 2007 17:29, Daniel Walker wrote: > > On Wed, 2007-09-05 at 14:43 +0100, Denys Vlasenko wrote: > > > Build system: section garbage collection for vmlinux > > > > > > > > > Newer gcc and binutils can do dead code and data removal > > > at link time. It is achieved using combination of > > > -ffunction-sections -fdata-sections options for gcc and > > > --gc-sections for ld. > > > > > > Theory of operation: > > > > > > Option -ffunction-sections instructs gcc to place each function > > > (including static ones) in it's own section named .text.function_name > > > instead of placing all functions in one big .text section. > > > > > > At link time, ld normally coalesce all such sections into one > > > output section .text again. It is achieved by having *(.text.*) spec > > > along with *(.text) spec in built-in linker scripts. > > > > You version doesn't work with CONFIG_MODULES right? > > It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you . Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 16:53, Oleg Verych wrote: > * Wed, 5 Sep 2007 14:43:21 +0100 > * User-Agent: KMail/1.9.1 > > > > Build system: section garbage collection for vmlinux > > Maybe this is just a test suit to get finish with `make XYZ static`? They are vaguely connected in a sense that unused function which is not marked static doesn't generate gcc warning, but will be discarded by --gc-sections. "make XYZ static" also tends to find them - you make function static, you recompile the file, and gcc informs you that the function is not used at all! This happened to me when I did aic7xxx patches. You may yse --print-gc-sections to see the list of discarded sections. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 17:29, Daniel Walker wrote: > On Wed, 2007-09-05 at 14:43 +0100, Denys Vlasenko wrote: > > Build system: section garbage collection for vmlinux > > > > > > Newer gcc and binutils can do dead code and data removal > > at link time. It is achieved using combination of > > -ffunction-sections -fdata-sections options for gcc and > > --gc-sections for ld. > > > > Theory of operation: > > > > Option -ffunction-sections instructs gcc to place each function > > (including static ones) in it's own section named .text.function_name > > instead of placing all functions in one big .text section. > > > > At link time, ld normally coalesce all such sections into one > > output section .text again. It is achieved by having *(.text.*) spec > > along with *(.text) spec in built-in linker scripts. > > You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. > Also, why do you need this patch, > > [PATCH 1/3] build system: section garbage collection for vmlinux Because otherwise, for example, .data.percpu sections we already have get picked up by *(.data.*), and then *(.data.percpu) end up empty: __per_cpu_start = .; *(.data.percpu) *(.data.percpu.shared_aligned) __per_cpu_end = .; and all hell breaks loose. We need to stop using sections named like .text. .data. .rodata. .bss. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 14:43 +0100, Denys Vlasenko wrote: > Build system: section garbage collection for vmlinux > > > Newer gcc and binutils can do dead code and data removal > at link time. It is achieved using combination of > -ffunction-sections -fdata-sections options for gcc and > --gc-sections for ld. > > Theory of operation: > > Option -ffunction-sections instructs gcc to place each function > (including static ones) in it's own section named .text.function_name > instead of placing all functions in one big .text section. > > At link time, ld normally coalesce all such sections into one > output section .text again. It is achieved by having *(.text.*) spec > along with *(.text) spec in built-in linker scripts. You version doesn't work with CONFIG_MODULES right? Also, why do you need this patch, [PATCH 1/3] build system: section garbage collection for vmlinux Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
* Wed, 5 Sep 2007 14:43:21 +0100 * User-Agent: KMail/1.9.1 > > Build system: section garbage collection for vmlinux > Maybe this is just a test suit to get finish with `make XYZ static`? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
* Wed, 5 Sep 2007 14:43:21 +0100 * User-Agent: KMail/1.9.1 Build system: section garbage collection for vmlinux Maybe this is just a test suit to get finish with `make XYZ static`? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 14:43 +0100, Denys Vlasenko wrote: Build system: section garbage collection for vmlinux Newer gcc and binutils can do dead code and data removal at link time. It is achieved using combination of -ffunction-sections -fdata-sections options for gcc and --gc-sections for ld. Theory of operation: Option -ffunction-sections instructs gcc to place each function (including static ones) in it's own section named .text.function_name instead of placing all functions in one big .text section. At link time, ld normally coalesce all such sections into one output section .text again. It is achieved by having *(.text.*) spec along with *(.text) spec in built-in linker scripts. You version doesn't work with CONFIG_MODULES right? Also, why do you need this patch, [PATCH 1/3] build system: section garbage collection for vmlinux Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 17:29, Daniel Walker wrote: On Wed, 2007-09-05 at 14:43 +0100, Denys Vlasenko wrote: Build system: section garbage collection for vmlinux Newer gcc and binutils can do dead code and data removal at link time. It is achieved using combination of -ffunction-sections -fdata-sections options for gcc and --gc-sections for ld. Theory of operation: Option -ffunction-sections instructs gcc to place each function (including static ones) in it's own section named .text.function_name instead of placing all functions in one big .text section. At link time, ld normally coalesce all such sections into one output section .text again. It is achieved by having *(.text.*) spec along with *(.text) spec in built-in linker scripts. You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Also, why do you need this patch, [PATCH 1/3] build system: section garbage collection for vmlinux Because otherwise, for example, .data.percpu sections we already have get picked up by *(.data.*), and then *(.data.percpu) end up empty: __per_cpu_start = .; *(.data.percpu) *(.data.percpu.shared_aligned) __per_cpu_end = .; and all hell breaks loose. We need to stop using sections named like .text. .data. .rodata. .bss. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 16:53, Oleg Verych wrote: * Wed, 5 Sep 2007 14:43:21 +0100 * User-Agent: KMail/1.9.1 Build system: section garbage collection for vmlinux Maybe this is just a test suit to get finish with `make XYZ static`? They are vaguely connected in a sense that unused function which is not marked static doesn't generate gcc warning, but will be discarded by --gc-sections. make XYZ static also tends to find them - you make function static, you recompile the file, and gcc informs you that the function is not used at all! This happened to me when I did aic7xxx patches. You may yse --print-gc-sections to see the list of discarded sections. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 19:37 +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 17:29, Daniel Walker wrote: On Wed, 2007-09-05 at 14:43 +0100, Denys Vlasenko wrote: Build system: section garbage collection for vmlinux Newer gcc and binutils can do dead code and data removal at link time. It is achieved using combination of -ffunction-sections -fdata-sections options for gcc and --gc-sections for ld. Theory of operation: Option -ffunction-sections instructs gcc to place each function (including static ones) in it's own section named .text.function_name instead of placing all functions in one big .text section. At link time, ld normally coalesce all such sections into one output section .text again. It is achieved by having *(.text.*) spec along with *(.text) spec in built-in linker scripts. You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you . Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 19:38, Daniel Walker wrote: You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. I also saw ~10% size reductions, but then at run-time test modules failed to load, they didn't find needed symbols. OTOH if I know that I am not going to be using such modules, then this can be done. Will require another CONFIG_xxx, though. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 20:14 +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 19:38, Daniel Walker wrote: You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. Right , so it doesn't work with modules.. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 02:43:21PM +0100, Denys Vlasenko wrote: Build system: section garbage collection for vmlinux Newer gcc and binutils can do dead code and data removal at link time. It is achieved using combination of -ffunction-sections -fdata-sections options for gcc and --gc-sections for ld. ... In the long term I'd like us to be able to compile the whole (or at least most of) the kernel with one -combine -fwhole-program gcc call which should bring the same positive effect plus enables gcc to do additional optimizations. That's meant as a remark, not against your patch (which is for a lower hanging fruit). vda cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 19:38, Daniel Walker wrote: You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. I also saw ~10% size reductions, but then at run-time test modules failed to load, they didn't find needed symbols. OTOH if I know that I am not going to be using such modules, then this can be done. Will require another CONFIG_xxx, though. One point to keep in mind is that the space penalty of CONFIG_MODULES=y is so big that CONFIG_MODULES=n is actually the most interesting case for small systems that really need small kernels. vda cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 21:31 +0200, Adrian Bunk wrote: On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 19:38, Daniel Walker wrote: You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. I also saw ~10% size reductions, but then at run-time test modules failed to load, they didn't find needed symbols. OTOH if I know that I am not going to be using such modules, then this can be done. Will require another CONFIG_xxx, though. One point to keep in mind is that the space penalty of CONFIG_MODULES=y is so big that CONFIG_MODULES=n is actually the most interesting case for small systems that really need small kernels. Marcelo's version actual deals with the CONFIG_MODULES=y penalty , which is interesting to me .. It removes symbols added for CONFIG_MODULES which actually aren't used .. So CONFIG_MODULES=y is just as interesting as without (to me at least..). Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 12:24:04PM -0700, Daniel Walker wrote: On Wed, 2007-09-05 at 21:31 +0200, Adrian Bunk wrote: On Wed, Sep 05, 2007 at 08:14:12PM +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 19:38, Daniel Walker wrote: You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. I also saw ~10% size reductions, but then at run-time test modules failed to load, they didn't find needed symbols. OTOH if I know that I am not going to be using such modules, then this can be done. Will require another CONFIG_xxx, though. One point to keep in mind is that the space penalty of CONFIG_MODULES=y is so big that CONFIG_MODULES=n is actually the most interesting case for small systems that really need small kernels. Marcelo's version actual deals with the CONFIG_MODULES=y penalty , which is interesting to me .. It removes symbols added for CONFIG_MODULES which actually aren't used .. So CONFIG_MODULES=y is just as interesting as without (to me at least..). There's still stuff like kernel/module.c or the additional space each used EXPORT_SYMBOL takes that make CONFIG_MODULES=n kernels smaller. But it depends on the use case: If you are aiming for the smallest possible runtime memory usage CONFIG_MODULES=n is the best choice, while for some applications where the bzimage (or similar) size is for some reason limited but the size of the modules doesn't matter the approach you mention might be the best. Daniel cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wednesday 05 September 2007 20:07, Daniel Walker wrote: On Wed, 2007-09-05 at 20:14 +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 19:38, Daniel Walker wrote: You version doesn't work with CONFIG_MODULES right? It works with CONFIG_MODULES. Really? Take a look at this version, http://lkml.org/lkml/2006/6/4/169 Marcello had to implement a two pass build to add back symbol used in modules which got removed from the main kernel.. You don't appear to do that. Marcelo also claims better size reduction than you. This will discard EXPORT_SYMBOLs potentially used by out-of-tree modules. Right, so it doesn't work with modules.. What does it stand for in this sentence? My patch was tested to work in my limited testing, but it is very conservative. I can't talk for Marcelo, but his patch probably worked too, it just didn't guarantee that you can install kernel, and then compile and load external module. Wel, it will compile, but maybe will fail to load. It sounds like *in-tree modules* were loading just fine for Marcelo. -- vda - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, 2007-09-05 at 20:49 +0100, Denys Vlasenko wrote: What does it stand for in this sentence? it is your patches, and I think we got to bottom of it .. it (i.e. your patches) don't actually work with modules, which is what you originally contended .. My patch was tested to work in my limited testing, but it is very conservative. I can't talk for Marcelo, but his patch probably worked too, it just didn't guarantee that you can install kernel, and then compile and load external module. Wel, it will compile, but maybe will fail to load. At least you should modify your Kconfig changes so that you don't allow people to select your new option unless they have CONFIG_MODULES off.. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 16:53, Oleg Verych wrote: * Wed, 5 Sep 2007 14:43:21 +0100 * User-Agent: KMail/1.9.1 Build system: section garbage collection for vmlinux Maybe this is just a test suit to get finish with `make XYZ static`? They are vaguely connected in a sense that unused function which is not marked static doesn't generate gcc warning, but will be discarded by --gc-sections. make XYZ static also tends to find them - you make function static, you recompile the file, and gcc informs you that the function is not used at all! This happened to me when I did aic7xxx patches. You may yse --print-gc-sections to see the list of discarded sections. Anyway, this is gccism/binutilizm. That about other possible/future options? Give me example, please, why function must be non static if not used. If usage requires kconfig tuning, then this is a better way to go, than to adopt yet another GNU/Luxury. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] build system: section garbage collection for vmlinux
On Wed, Sep 05, 2007 at 10:34:38PM +0200, Oleg Verych wrote: On Wed, Sep 05, 2007 at 07:46:11PM +0100, Denys Vlasenko wrote: On Wednesday 05 September 2007 16:53, Oleg Verych wrote: * Wed, 5 Sep 2007 14:43:21 +0100 * User-Agent: KMail/1.9.1 Build system: section garbage collection for vmlinux Maybe this is just a test suit to get finish with `make XYZ static`? They are vaguely connected in a sense that unused function which is not marked static doesn't generate gcc warning, but will be discarded by --gc-sections. make XYZ static also tends to find them - you make function static, you recompile the file, and gcc informs you that the function is not used at all! This happened to me when I did aic7xxx patches. You may yse --print-gc-sections to see the list of discarded sections. Anyway, this is gccism/binutilizm. That about other possible/future options? The kernel requires GNU gcc and GNU binutils, and if you want to use other tools for building the kernel they have to be sufficiently compatible. Give me example, please, why function must be non static if not used. s/not used/not used in this kernel configuration/ If usage requires kconfig tuning, then this is a better way to go, than to adopt yet another GNU/Luxury. The alternative would be to use an unmaintainable amount of #ifdef's. cu Adrian -- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
