linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Zlatko Calusic <zcalusic@bitsync.net>, Mel Gorman <mel@csn.ul.ie>,
	Rik van Riel <riel@redhat.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH RFC] mm: lru milestones, timestamps and ages
Date: Mon, 6 May 2013 15:08:02 -0400	[thread overview]
Message-ID: <20130506190802.GA16474@cmpxchg.org> (raw)
In-Reply-To: <5185069A.1080306@openvz.org>

Mel: we talked about this issue below in SFO, apparently I'm not the
only one who noticed :-)

Rik: a fix for the problem below is crucial for the refault
distance-based page cache sizing.  The unequal LRU aging is a problem
in itself, but it's compounded when we use the skewed non-resident
times to base reclaim decisions on

On Sat, May 04, 2013 at 05:01:14PM +0400, Konstantin Khlebnikov wrote:
> Hey! I can reproduce this:
> 
> Node 0, zone    DMA32
>     nr_inactive_anon 1
>     nr_active_anon 2368
>     nr_inactive_file 373642
>     nr_active_file 375462
>     nr_dirtied   2887369
>     nr_written   2887291
>   inactive_ratio:    5
>   avg_age_inactive_anon: 64942528
>   avg_age_active_anon:   64942528
>   avg_age_inactive_file: 389824
>   avg_age_active_file:   1330368
> Node 0, zone   Normal
>     nr_inactive_anon 376
>     nr_active_anon 17768
>     nr_inactive_file 534695
>     nr_active_file 533685
>     nr_dirtied   12071397
>     nr_written   11940007
>   inactive_ratio:    6
>   avg_age_inactive_anon: 65064192
>   avg_age_active_anon:   65064192
>   avg_age_inactive_file: 28074
>   avg_age_active_file:   1304800
> 
> I'm just copying huge files from one disk to another by rsync.
> 
> In /proc/vmstat pgsteal_kswapd_normal and pgscan_kswapd_normal are rising rapidly,
> other pgscan_* pgsteal_* are standing still. So, bug is somewhere in the kswapd.

There is a window where a steady stream of allocations and kswapd
cooperate in perfect unison and keep the Normal zone always between
the low and high watermarks.  Kswapd does not stop until the high
watermark is met, the allocator does not go to lower zones until the
low watermark is breached.  As a result, most allocations happen in
the Normal zone.

I'm playing around with a round-robin scheme on the page allocator
side to spread out file pages more evenly, but I'm torn on whether the
fix should actually be on the kswapd side, to enforce reclaim instead
of allocation more evenly.  Thoughts?

--
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>

  parent reply	other threads:[~2013-05-06 19:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-30 11:02 Konstantin Khlebnikov
2013-05-03 14:07 ` Zlatko Calusic
2013-05-04 11:53   ` Konstantin Khlebnikov
2013-05-04 13:01     ` Konstantin Khlebnikov
2013-05-04 21:36       ` Zlatko Calusic
2013-05-06 19:08       ` Johannes Weiner [this message]
2013-05-04 13:32     ` Zlatko Calusic
2013-05-10 10:28 ` Mel Gorman
2013-05-10 14:12   ` Konstantin Khlebnikov

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=20130506190802.GA16474@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=khlebnikov@openvz.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=riel@redhat.com \
    --cc=zcalusic@bitsync.net \
    /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