From: David Chinner <dgc@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: Bharata B Rao <bharata@in.ibm.com>, Theodore Ts'o <tytso@mit.edu>,
Dipankar Sarma <dipankar@in.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
manfred@colorfullife.com
Subject: Re: VM balancing issues on 2.6.13: dentry cache not getting shrunk enough
Date: Thu, 15 Sep 2005 08:48:05 +1000 [thread overview]
Message-ID: <20050914224805.GB2265486@melbourne.sgi.com> (raw)
In-Reply-To: <200509141101.16781.ak@suse.de>
On Wed, Sep 14, 2005 at 11:01:15AM +0200, Andi Kleen wrote:
> On Tuesday 13 September 2005 23:59, David Chinner wrote:
> > On Tue, Sep 13, 2005 at 02:17:52PM +0530, Bharata B Rao wrote:
> > > Second is Sonny Rao's rbtree dentry reclaim patch which is an attempt
> > > to improve this dcache fragmentation problem.
> >
> > FYI, in the past I've tried this patch to reduce dcache fragmentation on
> > an Altix (16k pages, 62 dentries to a slab page) under heavy
> > fileserver workloads and it had no measurable effect. It appeared
> > that there was almost always at least one active dentry on each page
> > in the slab. The story may very well be different on 4k page
> > machines, however.
>
> I always thought dentry freeing would work much better if it
> was turned upside down.
>
> Instead of starting from the high level dcache lists it could
> be driven by slab: on memory pressure slab tries to return pages with unused
> cache objects. In that case it should check if there are only
> a small number of pinned objects on the page set left, and if
> yes use a new callback to the higher level user (=dcache) and ask them
> to free the object.
If you add a slab free object callback, then you have the beginnings
of a more flexible solution to memory reclaim from the slabs.
For example, you can easily implement a reclaim-not-allocate method
for new slab allocations for when there is no memory available or the
size of the slab is passed some configurable high water mark...
Right now these is no way to control the size of a slab cache. Part
of the reason for the fragmentation I have seen is the massive
changes in size of the caches due to the OS making wrong decisions
about memory reclaim when small changes in the workload occur. We
currently have no way to provide hints to help the OS make the right
decision for a given workload....
Cheers,
Dave.
--
Dave Chinner
R&D Software Enginner
SGI Australian Software Group
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-09-14 22:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-11 10:57 Theodore Ts'o
2005-09-11 12:00 ` Dipankar Sarma
2005-09-12 3:16 ` Theodore Ts'o
2005-09-12 6:16 ` Martin J. Bligh
2005-09-12 12:53 ` Bharata B Rao
2005-09-13 8:47 ` Bharata B Rao
2005-09-13 21:59 ` David Chinner
2005-09-14 9:01 ` Andi Kleen
2005-09-14 9:16 ` Manfred Spraul
2005-09-14 9:43 ` Andrew Morton
2005-09-14 9:52 ` Dipankar Sarma
2005-09-14 22:44 ` Theodore Ts'o
2005-09-14 9:35 ` Andrew Morton
2005-09-14 13:57 ` Martin J. Bligh
2005-09-14 15:37 ` Sonny Rao
2005-09-15 7:21 ` Helge Hafting
2005-09-14 22:48 ` David Chinner [this message]
2005-09-14 15:48 ` Sonny Rao
2005-09-14 22:02 ` David Chinner
2005-09-14 22:40 ` Sonny Rao
2005-09-15 1:14 ` David Chinner
2005-10-06 6:27 ` [PATCH] dcache: separate slab for directory dentries David Chinner, gnb
2005-10-06 12:28 ` Dave Kleikamp
2005-10-07 3:54 ` Greg Banks
2005-10-07 13:00 ` Dave Kleikamp
2005-09-14 21:34 ` VM balancing issues on 2.6.13: dentry cache not getting shrunk enough Marcelo Tosatti
2005-09-14 21:43 ` Dipankar Sarma
2005-09-15 4:28 ` Bharata B Rao
2005-09-14 23:08 ` Marcelo Tosatti
2005-09-15 9:39 ` Bharata B Rao
2005-09-15 13:29 ` Marcelo Tosatti
2005-10-02 16:32 ` Bharata B Rao
2005-10-02 20:06 ` Marcelo
2005-10-04 13:36 ` shrinkable cache statistics [was Re: VM balancing issues on 2.6.13: dentry cache not getting shrunk enough] Bharata B Rao
2005-10-05 21:25 ` Marcelo Tosatti
2005-10-07 8:12 ` Bharata B Rao
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=20050914224805.GB2265486@melbourne.sgi.com \
--to=dgc@sgi.com \
--cc=ak@suse.de \
--cc=bharata@in.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=manfred@colorfullife.com \
--cc=tytso@mit.edu \
/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