From: Rik van Riel <riel@redhat.com>
To: Zlatko Calusic <zcalusic@bitsync.net>
Cc: Mel Gorman <mgorman@suse.de>, linux-mm <linux-mm@kvack.org>,
Konstantin Khlebnikov <khlebnikov@openvz.org>
Subject: Re: The pagecache unloved in zone NORMAL?
Date: Sun, 12 May 2013 13:53:16 -0400 [thread overview]
Message-ID: <518FD70C.7020608@redhat.com> (raw)
In-Reply-To: <5186D433.3050301@bitsync.net>
On 05/05/2013 05:50 PM, Zlatko Calusic wrote:
> An excellent Konstantin's patch better described here
> http://marc.info/?l=linux-mm&m=136731974301311 is already giving some
> useful additional insight into this problem, just as I expected. Here's
> the data after 31h of server uptime (also see the attached graph):
>
> Node 0, zone DMA32
> nr_inactive_file 443705
> avg_age_inactive_file: 362800
> Node 0, zone Normal
> nr_inactive_file 32832
> avg_age_inactive_file: 38760
>
> I reckon that only aging of the inactive LRU lists is of the interest at
> the moment, because there's currently a streaming I/O of about 8MB/s
> that can be seen on the graphs. Here's how I decipher the numbers:
> The only question I have is, is this a design mistake, or a plain bug?
I believe this is a bug.
> I strongly believe that pages should be reclaimed at speed appropriate
> to the LRU size.
I agree. Aging the pages in one zone 10x as fast as the pages in
another zone could throw off all kinds of things, including detecting
(and preserving) the system working set, page cache readahead thrashing,
etc...
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2013-05-12 17:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-11 20:30 Zlatko Calusic
2013-05-05 21:50 ` Zlatko Calusic
2013-05-09 20:24 ` Zlatko Calusic
2013-05-12 17:53 ` 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=518FD70C.7020608@redhat.com \
--to=riel@redhat.com \
--cc=khlebnikov@openvz.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--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