From: Andi Kleen <andi@firstfloor.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Waiman Long <Waiman.Long@hp.com>,
Andi Kleen <andi@firstfloor.org>,
linux-fsdevel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] dcache: make Oracle more scalable on large systems
Date: Sat, 23 Feb 2013 01:13:32 +0100 [thread overview]
Message-ID: <20130223001332.GA30494@two.firstfloor.org> (raw)
In-Reply-To: <20130222230048.GP26694@dastard>
> That seems to me like an application problem - poking at what the
> kernel is doing via diagnostic interfaces so often that it gets in
> the way of the kernel actually doing stuff is not a problem the
> kernel can solve.
I agree with you that the application shouldn't be doing that, but
if there is a cheap way to lower the d_path overhead that is also
attractive. There will be always applications doing broken things.
Any scaling problem less in the kernel is good.
But the real fix in this case is to fix the application.
-Andi
next prev parent reply other threads:[~2013-02-23 0:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 18:50 [PATCH 0/4] dcache: make Oracle more scalable on large systems Waiman Long
2013-02-19 18:50 ` [PATCH 1/4] dcache: Don't take unncessary lock in d_count update Waiman Long
2013-02-19 18:50 ` [PATCH 2/4] dcache: introduce a new sequence read/write lock type Waiman Long
2013-02-19 18:50 ` [PATCH 3/4] dcache: change rename_lock to a sequence read/write lock Waiman Long
2013-02-19 18:50 ` Waiman Long
2013-02-19 18:50 ` [PATCH 4/4] dcache: don't need to take d_lock in prepend_path() Waiman Long
2013-02-21 23:38 ` [PATCH 0/4] dcache: make Oracle more scalable on large systems Dave Chinner
2013-02-22 0:13 ` Andi Kleen
2013-02-22 4:13 ` Waiman Long
2013-02-22 23:00 ` Dave Chinner
2013-02-23 0:13 ` Andi Kleen [this message]
2013-02-28 20:39 ` Waiman Long
2013-02-28 23:13 ` Waiman Long
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=20130223001332.GA30494@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=Waiman.Long@hp.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.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;
as well as URLs for NNTP newsgroup(s).