From: Andrew Morton <akpm@digeo.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [patch] remove page->virtual
Date: Thu, 19 Sep 2002 22:41:44 -0700 [thread overview]
Message-ID: <3D8AB518.218F8503@digeo.com> (raw)
In-Reply-To: 20020920050320.GH3530@holomorphy.com
William Lee Irwin III wrote:
>
> On Thu, Sep 19, 2002 at 09:55:52PM -0700, Andrew Morton wrote:
> > set_page_address() and page_address() implementations consume 0.4% and
> > 1.3% of CPU time respectively. I think that's OK. (Plus the tested code
> > was doing an unneeded lookup in set_page_address(), for debug purposes)
>
> Looks yummy. I'll take it for a spin tonight on my benchmark-o-matic.
> Clearing some more air in ZONE_NORMAL is always welcome here.
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
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@digeo.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [patch] remove page->virtual
Date: Thu, 19 Sep 2002 22:41:44 -0700 [thread overview]
Message-ID: <3D8AB518.218F8503@digeo.com> (raw)
In-Reply-To: 20020920050320.GH3530@holomorphy.com
William Lee Irwin III wrote:
>
> On Thu, Sep 19, 2002 at 09:55:52PM -0700, Andrew Morton wrote:
> > set_page_address() and page_address() implementations consume 0.4% and
> > 1.3% of CPU time respectively. I think that's OK. (Plus the tested code
> > was doing an unneeded lookup in set_page_address(), for debug purposes)
>
> Looks yummy. I'll take it for a spin tonight on my benchmark-o-matic.
> Clearing some more air in ZONE_NORMAL is always welcome here.
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2002-09-20 5:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-20 4:55 [patch] remove page->virtual Andrew Morton
2002-09-20 4:55 ` Andrew Morton
2002-09-20 5:03 ` William Lee Irwin III
2002-09-20 5:03 ` William Lee Irwin III
2002-09-20 5:41 ` Andrew Morton [this message]
2002-09-20 5:41 ` Andrew Morton
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=3D8AB518.218F8503@digeo.com \
--to=akpm@digeo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wli@holomorphy.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.