Each test ran for about 15 seconds:
EXT2 kernel calls
==========
c022e080 6533 2.96616 __make_request /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c013df50 6592 2.99295 __block_prepare_write /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c012e880 7765 3.52552 generic_file_write_nolock /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c0175020 8588 3.89919 ext2_get_branch /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
Top 3:
c013cf70 8678 3.94005 get_hash_table /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c01752e0 10185 4.62427 ext2_get_block /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c022f8c0 14293 6.48941 elevator_linus_merge /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
EXT3 kernel calls
==========
c015f1c0 10928 3.00962 ext3_new_block /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c016bb40 11863 3.26713 journal_dirty_metadata /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c016fac0 12292 3.38527 journal_cancel_revoke /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c022f8c0 15519 4.27401 elevator_linus_merge /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
Top 3:
c013cf70 16380 4.51113 get_hash_table /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c016b090 22883 6.30209 do_get_write_access /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
c0164910 26375 7.2638 ext3_do_update_inode /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
Test preformed
=========
part of the contest package:
2) launch oprofile (if you use gui oprof_start &)
1) prepare commands
export tmpfile=foobar.log
before youn run io_halfmem click on "start profiler"
run io_halfmem
wait 15 seconds
op_time -l which will dump the calls and time.
Hi,
On Thu, Sep 19, 2002 at 01:42:58AM -0400, Shawn Starr wrote:
> EXT3 kernel calls
> ==========
> Top 3:
> c013cf70 16380 4.51113 get_hash_table /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
Same as ext2...
> c016b090 22883 6.30209 do_get_write_access /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
That's an inevitable penalty from the way ext3 does journaling --- you
get two copies of data if a filesystem operation updates a block that
is still being journaled (because we need to snapshot the old copy to
write to the journal). That's done when ext3 notifies an intent to
modify the old block, so all those copies show up in
do_get_write_access.
> c0164910 26375 7.2638 ext3_do_update_inode /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
I've got a fix for excessive CPU time spent here.
--Stephen
>> c0164910 26375 7.2638 ext3_do_update_inode
>> /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
>
> I've got a fix for excessive CPU time spent here.
Could you pass that around? or is it not ready for general consumption... ?
Thanks.
------
Michael Cohen
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
If the patch is 'stable' I'd like to bench/test it.
On September 23, 2002 08:06 pm, Michael Cohen wrote:
> >> c0164910 26375 7.2638 ext3_do_update_inode
> >> /lib/modules/2.4.20-pre7-rmap14a-xfs-uml-shawn12d/build/vmlinux
> >
> > I've got a fix for excessive CPU time spent here.
>
> Could you pass that around? or is it not ready for general consumption... ?
> Thanks.
>
>
> ------
> Michael Cohen