This explains why Unionfs was (is?) slow to load on the PPC, which was mentioned on the Unionfs list a few months ago.
Charles -------- Forwarded Message -------- From: linux-os (Dick Johnson) <[EMAIL PROTECTED]> Reply-To: linux-os (Dick Johnson) <[EMAIL PROTECTED]> To: Wilson Li <[EMAIL PROTECTED]> Cc: linux-kernel <[email protected]>, Samuel Masham <[EMAIL PROTECTED]> Subject: Re: Slow loading big kernel module in 2.6 on PPC platform Date: Fri, 30 Sep 2005 11:46:51 -0400 On Thu, 29 Sep 2005, Wilson Li wrote: > > >> --- "linux-os (Dick Johnson)" <[EMAIL PROTECTED]> wrote: >> >> On Wed, 28 Sep 2005, Wilson Li wrote: >> >> I have a module I am currently working on. It has some assembly >> stuff linked with it, so it was easy to modify. In the assembly >> I allocated 16 megabytes of static storage (using the .space >> keyword), >> first in the .data section, then in .rodata, then in .text. The >> .text section is where code exists. In no case did the module take >> more than 1/4 second to load. In all cases the size shown by >> `lsmod` >> reflected the enormous size of the module. >> >> Now, that's static storage. If your code uses kmalloc() and >> friends to allocate a lot of storage when it is being loaded, >> then that's a different story. FYI, when you see a kernel message >> on the screen, that's not necessarily when it was "printed". It >> gets buffered, you know. If you want to time-check when various >> sections get control, to find out what's eating the time, then >> put the jiffie count into your kernel messages. >> >> A simple macro using the __FUNCTION__ string and the jiffie >> count can go a long way towards finding out what's happening. >> >> For instance, I once had a problem with continuous interrupts >> from a device, that couldn't be cleared, until the device was >> initialized. That slowed the system to a stand-still until >> I found that. The fix was easy, do some initialization before >> attaching the interrupt, at least enough to quiet the board. >> This board had an empty FPGA, whos bits need to be loaded >> with a bit-banger to make it work. The pin connected to an >> interrupt was just whatever-it-was-from-the-factory, before >> the intelligence was loaded. That system took about a minute >> for the first kernel message to be printed. Sometimes the >> system was very quiet <forever> and needed to be kicked. >> >> >> Cheers, >> Dick Johnson >> Penguin : Linux version 2.6.13 on an i686 machine (5589.55 >> BogoMips). >> Warning : 98.36% of all statistics are fiction. >> >> **************************************************************** >> The information transmitted in this message is confidential and may >> be privileged. Any review, retransmission, dissemination, or other >> use of this information by persons or entities other than the >> intended recipient is prohibited. If you are not the intended >> recipient, please notify Analogic Corporation immediately - by >> replying to this message or by sending an email to >> [EMAIL PROTECTED] - and destroy all copies of this >> information, including any attachments, without reading or >> disclosing them. >> >> Thank you. > > Appreciate your advice and help. I finally tracked it down to the > function called in init_module() in kernel/module.c. > > /* Allow arches to frob section contents and sizes. */ > err = module_frob_arch_sections(hdr, sechdrs, secstrings, mod); > > which takes most of time (more then 99%) during module loading just > as the reply from Semuel earlier. > > Wilson Li > Yes. Look at the code in .../arch/ppc/kernel/module.c count_relocs() and you will see a quadratic (n ^2) example of how not to do something! This probably could be fixed as (n * 2) order, two passes, however in the meantime, you might want to make as many symbols as you can in your code static. Because of the quadratic relationship, a small change in the number of symbols will make a large change in the load-time! Cheers, Dick Johnson Penguin : Linux version 2.6.13 on an i686 machine (5589.55 BogoMips). Warning : 98.36% of all statistics are fiction. **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/ _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
