From: Andrew Morton <akpm@osdl.org>
To: Peter Chubb <peter@chubb.wattle.id.au>
Cc: viro@parcelfarce.linux.theplanet.co.uk, davem@redhat.com,
cw@f00f.org, peter@chubb.wattle.id.au,
linux-kernel@vger.kernel.org
Subject: Re: stat very inefficient
Date: Thu, 29 Jul 2004 00:42:42 -0700 [thread overview]
Message-ID: <20040729004242.7601f777.akpm@osdl.org> (raw)
In-Reply-To: <16648.42669.907048.112765@wombat.chubb.wattle.id.au>
Peter Chubb <peter@chubb.wattle.id.au> wrote:
>
> The nice thing about the current three-copy implementation is that
> it's simple and obviously correct. Personally, I don't think that the
> increased complexity of arhcitecture-specific callbacks, etc., is
> worth the small performance gain.
>
hmm. Here's a Pentium III profile of a 260,000-file
`find 00000000 -type f -mtime 2000':
00000000c015fcb0 __user_walk 233 3.0658
00000000c0122498 current_kernel_time 241 3.5441
00000000c01700b0 __mark_inode_dirty 263 0.7225
00000000c016dacc set_fs_pwd 264 1.8333
00000000c0163510 vfs_readdir 315 2.3864
00000000c01f9fc8 copy_to_user 330 4.8529
00000000c01375f0 find_get_page 332 4.3684
00000000c015e7e4 path_release 368 6.5714
00000000c015e580 getname 381 2.3813
00000000c0143c0c set_page_address 411 1.0275
00000000c0143b80 page_address 449 3.2071
00000000c01a1cc0 ext2_readdir 482 0.8087
00000000c01637fc filldir64 499 2.2277
00000000c01678b0 dput 533 1.1897
00000000c013f4b8 kmem_cache_alloc 612 7.2857
00000000c013f794 kmem_cache_free 625 8.2237
00000000c01f9c98 strncpy_from_user 695 8.2738
00000000c015eb2c do_lookup 738 5.5909
00000000c01f9db0 __copy_user_intel 741 4.6312
00000000c01f9510 atomic_dec_and_lock 801 10.6800
00000000c015b488 cp_new_stat64 1065 4.2262
00000000c01f9ef0 __copy_to_user_ll 1090 10.4808
00000000c015af14 vfs_getattr 1097 8.3106
00000000c0105c0f sysenter_past_esp 1201 10.6283
00000000c015ae70 generic_fillattr 1815 11.0671
00000000c015fa1c path_lookup 1833 4.9810
00000000c015ebb0 link_path_walk 1915 0.5940
00000000c0168710 __d_lookup 6170 22.0357
00000000c0104034 default_idle 108054 1929.5357
0000000000000000 total 138203 0.0547
next prev parent reply other threads:[~2004-07-29 7:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <233602095@toto.iv>
2004-07-28 22:33 ` Peter Chubb
2004-07-28 22:45 ` David S. Miller
2004-07-29 0:08 ` Chris Wedgwood
2004-07-29 0:14 ` David S. Miller
2004-07-29 0:24 ` Chris Wedgwood
2004-07-29 0:29 ` viro
2004-07-29 7:26 ` Peter Chubb
2004-07-29 7:42 ` Andrew Morton [this message]
2004-07-29 8:49 ` Paul Jackson
2004-07-29 9:02 ` Andrew Morton
2004-07-29 9:17 ` Peter Chubb
2004-07-29 7:45 ` Ulrich Drepper
2004-07-29 11:42 ` Nigel Rantor
2004-07-29 1:07 ` Ulrich Drepper
2004-07-29 2:22 ` Paul Jackson
2004-07-29 4:10 ` Ulrich Drepper
2004-07-29 6:18 ` Paul Jackson
[not found] <2mN94-3MP-9@gated-at.bofh.it>
2004-07-28 10:16 ` Andi Kleen
2004-07-28 15:38 ` David S. Miller
2004-07-28 3:13 David S. Miller
2004-07-28 18:07 ` viro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040729004242.7601f777.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=cw@f00f.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter@chubb.wattle.id.au \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®