From: Nick Piggin <npiggin@kernel.dk>
To: Ying Han <yinghan@google.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Minchan Kim <minchan.kim@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
Nick Piggin <npiggin@gmail.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] Pass priority to shrink_slab
Date: Thu, 18 Nov 2010 19:59:21 +1100 [thread overview]
Message-ID: <20101118085921.GA11314@amd> (raw)
In-Reply-To: <1290054891-6097-1-git-send-email-yinghan@google.com>
On Wed, Nov 17, 2010 at 08:34:51PM -0800, Ying Han wrote:
> Pass the reclaim priority down to the shrink_slab() which passes to the
> shrink_icache_memory() for inode cache. It helps the situation when
> shrink_slab() is being too agressive, it removes the inode as well as all
> the pages associated with the inode. Especially when single inode has lots
> of pages points to it. The application encounters performance hit when
> that happens.
>
> The problem was observed on some workload we run, where it has small number
> of large files. Page reclaim won't blow away the inode which is pinned by
> dentry which in turn is pinned by open file descriptor. But if the application
> is openning and closing the fds, it has the chance to trigger the issue.
>
> I have a script which reproduce the issue. The test is creating 1500 empty
> files and one big file in a cgroup. Then it starts adding memory pressure
> in the cgroup. Both before/after the patch we see the slab drops (inode) in
> slabinfo but the big file clean pages being preserves only after the change.
I was going to do this as a flag when nearing OOM. Is there a reason
to have it priority based? That seems a little arbitrary to me...
FWIW, we can just add this to the new shrinker API, and convert over
the users who care about it, so it doesn't have to be done in a big
patch.
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-11-18 8:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 4:34 [PATCH] Pass priority to shrink_slab Ying Han
2010-11-18 8:59 ` Nick Piggin [this message]
2010-11-18 10:06 ` Ying Han
2010-11-18 10:24 ` Michel Lespinasse
2010-11-19 22:25 ` Andrew Morton
2010-11-20 3:23 ` Ying Han
2010-11-22 23:06 ` Andrew Morton
2010-11-23 2:09 ` Michel Lespinasse
2010-11-23 2:26 ` 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=20101118085921.GA11314@amd \
--to=npiggin@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=npiggin@gmail.com \
--cc=riel@redhat.com \
--cc=yinghan@google.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.