From: Rik van Riel <riel@redhat.com>
To: Minchan Kim <minchan@kernel.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Dave Chinner <david@fromorbit.com>,
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: Tue, 10 Jan 2012 20:17:07 -0500 [thread overview]
Message-ID: <4F0CE313.1090008@redhat.com> (raw)
In-Reply-To: <20111227035730.GA22840@barrios-laptop.redhat.com>
On 12/26/2011 10:57 PM, Minchan Kim wrote:
> I guess it's caused by small NORMAL zone.
> The scenario I think is as follows,
I guess it is exaggerated by a small NORMAL zone. Even on my
system, where the NORMAL zone is about 3x as large as the DMA32
zone, I can see that the pages in the NORMAL zone get recycled
slightly faster than those in the DMA32 zone...
> 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.
I wonder if it would make sense for kswapd to count how many
pages it needs to free in each zone (at step 2), and then stop
reclaiming once it has freed that many pages.
That could leave the NORMAL (or HIGHMEM, on 32 bit) zone below
the watermark, but as long as the other zones are still good,
allocations can proceed just fine.
It would have the disadvantage of kswapd stopping reclaim with
possibly a zone below the watermark, but the advantage of
better balancing of allocations between zones.
Does this idea make sense?
--
All rights reversed
--
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>
prev parent reply other threads:[~2012-01-11 1:17 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
2012-01-11 1:17 ` Rik van Riel [this message]
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=4F0CE313.1090008@redhat.com \
--to=riel@redhat.com \
--cc=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).