All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@gamebox.net>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: dcache_rcu [performance results]
Date: Sat, 2 Nov 2002 16:24:19 +0530	[thread overview]
Message-ID: <20021102162419.A7894@dikhow> (raw)
In-Reply-To: <p734rb0s2qb.fsf@oldwotan.suse.de>; from ak@suse.de on Sat, Nov 02, 2002 at 11:08:44AM +0100

On Sat, Nov 02, 2002 at 11:08:44AM +0100, Andi Kleen wrote:
> Dipankar Sarma <woofwoof@hathway.com> writes:
> > 
> > I should add that this is a general trend we see in all workloads
> > that do a lot of open/closes and so much so that performance is very
> > sensitive to how close to / your application's working directory
> > is. You would get much better system time if you compile a kernel
> > in /linux as compared to say /home/fs01/users/akpm/kernel/linux ;-)
> 
> That's interesting. Perhaps it would make sense to have a fast path
> that just does a string match of the to be looked up path to a cached copy 
> of cwd and if it matches works as if cwd was the root. Would need to be 
> careful with chroot where cwd could be outside the root and clear the
> cached copy in this case. Then you could avoid all the locking overhead
> for directories above your cwd if you stay in there.

Well, on second thoughts I can't see why the path length for pwd
would make difference for kernel compilation - it uses relative
path and for path lookup, if the first character is not '/', then
lookup is done relative to current->fs->pwd. I will do some more
benchmarking on and verify.

I did get inputs from Troy Wilson who does specweb measurements
that the path name length of the location of the served files
make a difference. I presume his webserver setup used full path names.

Thanks
Dipankar

  reply	other threads:[~2002-11-02 10:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20021030161912.E2613@in.ibm.com.suse.lists.linux.kernel>
     [not found] ` <20021031162330.B12797@in.ibm.com.suse.lists.linux.kernel>
     [not found]   ` <3DC32C03.C3910128@digeo.com.suse.lists.linux.kernel>
     [not found]     ` <20021102144306.A6736@dikhow.suse.lists.linux.kernel>
2002-11-02 10:08       ` dcache_rcu [performance results] Andi Kleen
2002-11-02 10:54         ` Dipankar Sarma [this message]
2002-11-02 11:01           ` Andi Kleen
2002-11-02 19:41             ` Linus Torvalds
2002-11-02 21:16               ` Sam Ravnborg
2002-10-30 10:49 [PATCH 2.5.44] dcache_rcu Maneesh Soni
2002-10-31 10:53 ` dcache_rcu [performance results] Dipankar Sarma
2002-11-02  1:36   ` Andrew Morton
2002-11-02  9:13     ` Dipankar Sarma
2002-11-04 17:29       ` Martin J. Bligh
2002-11-05  0:00         ` jw schultz

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=20021102162419.A7894@dikhow \
    --to=dipankar@gamebox.net \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.