Re: [OT] Argument with an OS professor over profile=3
On 10/10/07, David Newall <[EMAIL PROTECTED]> wrote: > Russ Dill wrote: > > I've been having a back and forth going for a while with my TA and OS > > professor on the meaning of profile=3 and have been unable to convince > > either of them. The basic question is if profile=3 is passed to kernel > > with an 8MB text section, how big is the allocated profile buffer. His > > answer is 1MB > > > > if (prof_shift) { > > unsigned int size; > > /* only text is profiled */ > > prof_len = (unsigned *) &_etext - (unsigned *) &_stext; > > > You stipulated 8MB text, but this calculates in unsigned ints, so > prof_len = 2M. Please have a look at my followup, I accidentally sent out code that I had used to produce an answer as my prof thought it works. The actual code casts to (unsigned long). Sigh, I've shot myself in the foot... Anyway, the book (and the class covers 2.4.1) and the associated code has since moved from init/main.c. Here's how the 2.4.1ish code looks: http://tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/init_main.html - 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: [OT] Argument with an OS professor over profile=3
Russ Dill wrote: I've been having a back and forth going for a while with my TA and OS professor on the meaning of profile=3 and have been unable to convince either of them. The basic question is if profile=3 is passed to kernel with an 8MB text section, how big is the allocated profile buffer. His answer is 1MB if (prof_shift) { unsigned int size; /* only text is profiled */ prof_len = (unsigned *) &_etext - (unsigned *) &_stext; You stipulated 8MB text, but this calculates in unsigned ints, so prof_len = 2M. prof_len >>= prof_shift; This gives 250K (divide by 8). size = prof_len * sizeof(unsigned int) + PAGE_SIZE-1; Finally, size is 1MB (250K x 4). prof_buffer = (unsigned int *) alloc_bootmem(size); } I'm with your Prof. Perhaps you missed that prof_len counts integers, not bytes. - 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: [OT] Argument with an OS professor over profile=3
On Oct 11 2007 00:13, Russ Dill wrote: > >/* only text is profiled */ >> prof_len = (unsigned *) &_etext - (unsigned *) &_stext; Uh, that's some evil pointer arithmetic :) - 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: [OT] Argument with an OS professor over profile=3
/* only text is profiled */ > prof_len = (unsigned *) &_etext - (unsigned *) &_stext; Crap, sorry, accidentally sent a version I had laying around demonstrating how one *would* get the answer he expects. The correct line is of course: prof_len = (unsigned long) &_etext - (unsigned long) &_stext; - 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/
[OT] Argument with an OS professor over profile=3
I've been having a back and forth going for a while with my TA and OS professor on the meaning of profile=3 and have been unable to convince either of them. The basic question is if profile=3 is passed to kernel with an 8MB text section, how big is the allocated profile buffer. His answer is 1MB if (prof_shift) { unsigned int size; /* only text is profiled */ prof_len = (unsigned *) &_etext - (unsigned *) &_stext; prof_len >>= prof_shift; size = prof_len * sizeof(unsigned int) + PAGE_SIZE-1; prof_buffer = (unsigned int *) alloc_bootmem(size); } I've booted linux with profile=3 and pointed to the dmesg output. I've copied the code out of init/main.c into a test program and run it. I've even pointed to the comment in the Makefile for linux-0.98. He seems to think that there is pointer arithmetic taking place. To make matters worse, our textbook "Linux Core Kernel Commentary, 2nd Edition", also has an incorrect answer. It states "A prof_shift value of 2, for example, allocates an amount of memory equal to 25 percent of the kernel's code size to profile the kernel." And of course, he's been giving the exam for 4 years and no one else complained. Anyway, a reply from whoever sent this message back in 1992: http://groups.google.com/group/comp.os.linux/browse_thread/thread/d84462f394d3a206/dfee60779481ccec?lnk=st==4#dfee60779481ccec > I wrote a kernel profiling utility for this, and sent the patches > (small) and a user-level program to print out results (even smaller) to > the kernel mailing-list. If anybody sees this slow-down problem, and > tries out the profiling code, I'd be interested to have some sample > output. > > If you aren't on the kernel list, I can make the patches available on > the net. would be nice. I heard he had arguments with his OS prof's back in the day. (even neater if someone had the email that was sent to whatever that kernel list was, just for my general curiosity), but emails from others would be nice too :) A few secondary questions that aren't nearly as important. Is IRQ used an abbreviation for interrupt, or does it have a separate meaning to kernel developers? Rate the following responses on a scale from 1-10: Why does the source code use 14 calls to BUILD_16_IRQS each of which makes 16 calls to BI (which expands to BUILD_IRQ) instead of 224 calls to BUILD_IRQ? Reduce amount of source code and redundancy 224 calls would be ugly and difficult to maintain. Plus, kernel developers are lazv, they don't want to have to copy 224 times. Thanks, I work full time and attend graduate school full time, I've already spent far too much time arguing with my prof and TA. - 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: [OT] Argument with an OS professor over profile=3
On Oct 11 2007 00:13, Russ Dill wrote: /* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; Uh, that's some evil pointer arithmetic :) - 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/
[OT] Argument with an OS professor over profile=3
I've been having a back and forth going for a while with my TA and OS professor on the meaning of profile=3 and have been unable to convince either of them. The basic question is if profile=3 is passed to kernel with an 8MB text section, how big is the allocated profile buffer. His answer is 1MB if (prof_shift) { unsigned int size; /* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; prof_len = prof_shift; size = prof_len * sizeof(unsigned int) + PAGE_SIZE-1; prof_buffer = (unsigned int *) alloc_bootmem(size); } I've booted linux with profile=3 and pointed to the dmesg output. I've copied the code out of init/main.c into a test program and run it. I've even pointed to the comment in the Makefile for linux-0.98. He seems to think that there is pointer arithmetic taking place. To make matters worse, our textbook Linux Core Kernel Commentary, 2nd Edition, also has an incorrect answer. It states A prof_shift value of 2, for example, allocates an amount of memory equal to 25 percent of the kernel's code size to profile the kernel. And of course, he's been giving the exam for 4 years and no one else complained. Anyway, a reply from whoever sent this message back in 1992: http://groups.google.com/group/comp.os.linux/browse_thread/thread/d84462f394d3a206/dfee60779481ccec?lnk=stq=rnum=4#dfee60779481ccec I wrote a kernel profiling utility for this, and sent the patches (small) and a user-level program to print out results (even smaller) to the kernel mailing-list. If anybody sees this slow-down problem, and tries out the profiling code, I'd be interested to have some sample output. If you aren't on the kernel list, I can make the patches available on the net. would be nice. I heard he had arguments with his OS prof's back in the day. (even neater if someone had the email that was sent to whatever that kernel list was, just for my general curiosity), but emails from others would be nice too :) A few secondary questions that aren't nearly as important. Is IRQ used an abbreviation for interrupt, or does it have a separate meaning to kernel developers? Rate the following responses on a scale from 1-10: Why does the source code use 14 calls to BUILD_16_IRQS each of which makes 16 calls to BI (which expands to BUILD_IRQ) instead of 224 calls to BUILD_IRQ? Reduce amount of source code and redundancy 224 calls would be ugly and difficult to maintain. Plus, kernel developers are lazv, they don't want to have to copypaste 224 times. Thanks, I work full time and attend graduate school full time, I've already spent far too much time arguing with my prof and TA. - 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: [OT] Argument with an OS professor over profile=3
/* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; Crap, sorry, accidentally sent a version I had laying around demonstrating how one *would* get the answer he expects. The correct line is of course: prof_len = (unsigned long) _etext - (unsigned long) _stext; - 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: [OT] Argument with an OS professor over profile=3
On 10/10/07, David Newall [EMAIL PROTECTED] wrote: Russ Dill wrote: I've been having a back and forth going for a while with my TA and OS professor on the meaning of profile=3 and have been unable to convince either of them. The basic question is if profile=3 is passed to kernel with an 8MB text section, how big is the allocated profile buffer. His answer is 1MB if (prof_shift) { unsigned int size; /* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; You stipulated 8MB text, but this calculates in unsigned ints, so prof_len = 2M. Please have a look at my followup, I accidentally sent out code that I had used to produce an answer as my prof thought it works. The actual code casts to (unsigned long). Sigh, I've shot myself in the foot... Anyway, the book (and the class covers 2.4.1) and the associated code has since moved from init/main.c. Here's how the 2.4.1ish code looks: http://tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/init_main.html - 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: [OT] Argument with an OS professor over profile=3
Russ Dill wrote: I've been having a back and forth going for a while with my TA and OS professor on the meaning of profile=3 and have been unable to convince either of them. The basic question is if profile=3 is passed to kernel with an 8MB text section, how big is the allocated profile buffer. His answer is 1MB if (prof_shift) { unsigned int size; /* only text is profiled */ prof_len = (unsigned *) _etext - (unsigned *) _stext; You stipulated 8MB text, but this calculates in unsigned ints, so prof_len = 2M. prof_len = prof_shift; This gives 250K (divide by 8). size = prof_len * sizeof(unsigned int) + PAGE_SIZE-1; Finally, size is 1MB (250K x 4). prof_buffer = (unsigned int *) alloc_bootmem(size); } I'm with your Prof. Perhaps you missed that prof_len counts integers, not bytes. - 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/