Ta.
> On Thu, Sep 19, 2002 at 09:55:52PM -0700, Andrew Morton wrote:
> > c01884f2 6914 10.5108 .text.lock.dir
> > c01546b3 5847 8.88872 .text.lock.namei
> > c01eb99e 3811 5.79355 .text.lock.dec_and_lock
> > c01515dc 3775 5.73883 link_path_walk
> > c015207c 3567 5.42262 path_lookup
> > c015aba4 3194 4.85558 __d_lookup
> > c01eb690 2814 4.2779 __generic_copy_to_user
> > c01eb950 2562 3.8948 atomic_dec_and_lock
> > c0187580 2473 3.7595 ext2_readdir
> > c0155d3c 2172 3.30192 filldir64
> > c0151114 1786 2.71511 path_release
> > c0145b6a 1753 2.66494 .text.lock.open
>
> What's going on here? fs stuff is really hurting. At any rate, the
> overhead of the address calculation and hashtable lookup is microscopic
> according to this, and I want space.
c0182f90 5949 14.5552 ext2_readdir
lock_kernel()
c014f65c 5790 14.1662 path_lookup
Confused. oprofile claims read_lock(¤t->fs->lock) but
it's surely dcache_lock.
c01e6e80 4275 10.4595 atomic_dec_and_lock
dput/iput
c014eba4 2264 5.53924 link_path_walk
c0158050 1988 4.86397 __d_lookup
c01426e8 1903 4.656 sys_chdir
c01e6bc0 1735 4.24496 __generic_copy_to_user
c015319c 1344 3.28831 filldir64
c014e6b4 1205 2.94823 path_release
c0109070 1065 2.6057 system_call
c014b934 929 2.27295 cp_new_stat64
c014b380 822 2.01116 generic_fillattr
c0157250 712 1.74202 dput
c014b3fc 622 1.52182 vfs_getattr
c0157468 556 1.36034 dget_locked
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/