OProfile

I've now got the patch working for labelling .text.lock out-of-line code
in the kernel (which correspond to contention points) working.

Example output (CLK_UNHALTED,25000 on dual PII-400, kernel compiles +
oprofiled) :

c025f7b0 63834    0.0638729   stext_lock
	- (contention 0.06% of the total time)

...
2651 hits (4.15295923802362%): &kernel_flag in acct.c:352
2804 hits (4.39264341886769%): lock in dec_and_lock.c:35
2851 hits (4.46627189272175%): &kernel_flag in inode.c:521
4884 hits (7.65109502772817%): &zone->lock in page_alloc.c:183
5741 hits (8.99363975310963%): &zone->lock in page_alloc.c:104
6196 hits (9.70642604254786%): &kernel_flag in readdir.c:26
12645 hits (19.8091925932888%): &dcache_lock in dcache.c:712

I suppose the dcache_lock problem is mostly oprofile's use of d_path :/

The attached patch is against 2.4.17 (2.4.18 makes some important
changes in this area).

It still needs some cleaning up, and needs to be tested with a current
binutils.

Also attached is the perl script (slow) to generate the output above.
Eventually the post-profiling tools will be able to output such
information itself.

Anyway, it was fun hacking this to work ;)

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: Lock metering patch From: Dave Jones <davej@su...> - 2002-03-05 17:24 On Tue, Mar 05, 2002 at 05:01:11PM +0000, John Levon wrote: > > I've now got the patch working for labelling .text.lock out-of-line code > in the kernel (which correspond to contention points) working. > 2651 hits (4.15295923802362%): &kernel_flag in acct.c:352 > 2804 hits (4.39264341886769%): lock in dec_and_lock.c:35 > 2851 hits (4.46627189272175%): &kernel_flag in inode.c:521 > 4884 hits (7.65109502772817%): &zone->lock in page_alloc.c:183 > 5741 hits (8.99363975310963%): &zone->lock in page_alloc.c:104 > 6196 hits (9.70642604254786%): &kernel_flag in readdir.c:26 > 12645 hits (19.8091925932888%): &dcache_lock in dcache.c:712 That's really cool, I like that. Quite a lot. I imagine the LSE folks will too. I'm wondering if it can be further instrumented to show the actual contention. Ie, something like.. "%40 of the these samples we were able to take the lock with no contention" -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs

Re: Lock metering patch From: Philippe Elie <ph_e@cl...> - 2002-03-06 02:53 Attachments: gen-ldscript.pl.gz      From: "John Levon" <levon@...> Sent: Tuesday, March 05, 2002 6:01 PM > > I've now got the patch working for labelling .text.lock out-of-line code > in the kernel (which correspond to contention points) working. .... > Also attached is the perl script (slow) to generate the output above. > Eventually the post-profiling tools will be able to output such > information itself. > > Anyway, it was fun hacking this to work ;) Must we open a tools directory in oprofile with such things ? I think with a few explanation on how to use it it can be useful. I have currently a perl script that create from a samples files a ld scripts to improve code locality so on less code page fault and improvements of performance through a better tlb cache use and less ram page bank switch. (Only tested on povray gain 4% on speed) The nice thing is you can improve (slightly) code performance w/o touching the code of an application :) I join the script which is (poorly self explicating) regard, Phil

Re: Lock metering patch From: John Levon <levon@mo...> - 2002-03-06 06:49 On Wed, Mar 06, 2002 at 03:43:55AM +0100, Philippe Elie wrote: > Must we open a tools directory in oprofile with such things ? I think > with a few explanation on how to use it it can be useful. I have Yes. > currently a perl script that create from a samples files a ld scripts > to improve code locality so on less code page fault and improvements > of performance through a better tlb cache use and less ram page bank > switch. (Only tested on povray gain 4% on speed) The nice thing is > you can improve (slightly) code performance w/o touching the code of > an application :) I join the script which is (poorly self explicating) nice. Someone at the uni had a project to do a more ambitious basic-block level re-ordering utility, I'm not sure how far they actually got. I should follow that up. regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.

Re: Lock metering patch From: Philippe Elie <ph_e@cl...> - 2002-03-06 21:48 From: "John Levon" <levon@...> Sent: Wednesday, March 06, 2002 7:46 AM > On Wed, Mar 06, 2002 at 03:43:55AM +0100, Philippe Elie wrote: [improving code locality] > nice. Someone at the uni had a project to do a more ambitious > basic-block level re-ordering utility, I'm not sure how far they > actually got. I should follow that up. Have you a link ? Gcc compiler can make, at least partially, this but it make that at function level only and not at application neither translation unit level. regards Phil

Re: Lock metering patch From: John Levon <levon@mo...> - 2002-03-06 22:01 On Wed, Mar 06, 2002 at 07:05:17PM +0100, Philippe Elie wrote: > Have you a link ? I don't, but there's a number of papers and the like on the web about this area. regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.

609 messages have been excluded from this view by a project administrator.