From: Dave Chinner <david@fromorbit.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan@kernel.org>,
nowhere <nowhere@hakkenden.ath.cx>, Michal Hocko <mhocko@suse.cz>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Kswapd in 3.2.0-rc5 is a CPU hog
Date: Wed, 11 Jan 2012 11:33:22 +1100 [thread overview]
Message-ID: <20120111003322.GE24410@dastard> (raw)
In-Reply-To: <20111227135658.08c8016a.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, Dec 27, 2011 at 01:56:58PM +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 27 Dec 2011 12:57:31 +0900
> Minchan Kim <minchan@kernel.org> wrote:
> > The scenario I think is as follows,
> >
> > 1. dd comsumes memory in NORMAL zone
> > 2. dd enter direct reclaim and wakeup kswapd
> > 3. kswapd reclaims some memory in NORMAL zone until it reclaims high wamrk
> > 4. schedule
> > 5. dd consumes memory again in NORMAL zone
> > 6. kswapd fail to reclaim memory by high watermark due to 5.
> > 7. loop again, goto 3.
> >
> > The point is speed between reclaim VS memory consumption.
> > So kswapd cannot reach a point which enough pages are in NORMAL zone.
> >
> > >
> > > BTW. I'm sorry if I miss something ...Why only kswapd reclaims memory
> > > while 'dd' operation ? (no direct relcaim by dd.)
> > > Is this log record cpu hog after 'dd' ?
> >
> > If above scenario is right, dd couldn't enter direct reclaim to reclaim memory.
> >
>
> I think you're right. IIUC, kswapd's behavior is what we usually see.
>
> Hmm, if I understand correctly,
>
> - dd's speed down is caused by kswapd's cpu consumption.
> - kswapd's cpu consumption is enlarged by shrink_slab() (by perf)
> - kswapd can't stop because NORMAL zone is small.
> - memory reclaim speed is enough because dd can't get enough cpu.
>
> I wonder reducing to call shrink_slab() may be a help but I'm not sure
> where lock conention comes from...
There is no lock contention. It's simply the overhead of grabbing a
passive reference to every superblock in the machine 3 times every
100uS.
FWIW, I don't think kswapd should be polling the shrinkers this
often when there are no/very few pages available to be freed from
the slab caches. There are many more shrinkers now than there were
in the past, so the overhead of polling all shrinkers very quickly
is significant.
FWIW, when we move to locality aware shrinkers, the polling overhead
is going to be even higher, so either the VM needs to call
shrink_slab less aggressively, or shrink_slab() needs to have some
method of reducing shrinker polling frequency.....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-01-11 0:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1324437036.4677.5.camel@hakkenden.homenet>
2011-12-21 9:52 ` Kswapd in 3.2.0-rc5 is a CPU hog Michal Hocko
2011-12-21 10:15 ` nowhere
2011-12-21 10:24 ` Michal Hocko
2011-12-21 10:52 ` nowhere
2011-12-21 14:06 ` Alex Elder
2011-12-21 14:19 ` nowhere
2011-12-21 22:55 ` Dave Chinner
2011-12-23 9:01 ` nowhere
2011-12-23 10:20 ` Dave Chinner
2011-12-23 11:04 ` nowhere
2011-12-23 20:45 ` Dave Chinner
2011-12-25 9:09 ` Hillf Danton
2011-12-25 10:21 ` Nikolay S.
2011-12-26 12:35 ` Hillf Danton
2011-12-27 0:20 ` KAMEZAWA Hiroyuki
2011-12-27 13:33 ` Hillf Danton
2011-12-28 0:06 ` KAMEZAWA Hiroyuki
2011-12-27 2:15 ` KAMEZAWA Hiroyuki
2011-12-27 2:50 ` Nikolay S.
2011-12-27 4:44 ` KAMEZAWA Hiroyuki
2011-12-27 6:06 ` nowhere
2011-12-28 21:33 ` Dave Chinner
2011-12-28 22:57 ` KOSAKI Motohiro
2012-01-02 7:00 ` Dave Chinner
2011-12-27 3:57 ` Minchan Kim
2011-12-27 4:56 ` KAMEZAWA Hiroyuki
2012-01-10 22:33 ` Andrew Morton
2012-01-11 3:25 ` Nikolay S.
2012-01-11 4:42 ` Andrew Morton
2012-01-11 0:33 ` Dave Chinner [this message]
2012-01-11 1:17 ` Rik van Riel
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=20120111003322.GE24410@dastard \
--to=david@fromorbit.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=minchan@kernel.org \
--cc=nowhere@hakkenden.ath.cx \
/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).