From: Rik van Riel <riel@surriel.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH 5/5] mm/vmscan: don't forcely shrink active anon lru list
Date: Tue, 26 Feb 2019 09:42:45 -0500 [thread overview]
Message-ID: <63491909d5c7011b946a354000caace11d63cb84.camel@surriel.com> (raw)
In-Reply-To: <ea0f769b-29e6-8787-7b18-cb7b24c1cda3@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
On Tue, 2019-02-26 at 15:04 +0300, Andrey Ryabinin wrote:
> I think we should leave anon aging only for !SCAN_FILE cases.
> At least aging was definitely invented for the SCAN_FRACT mode which
> was the
> main mode at the time it was added by the commit:
> and I think would be reasonable to avoid the anon aging in the
> SCAN_FILE case.
> Because if workload generates enough inactive file pages we never go
> to the SCAN_FRACT,
> so aging is just as useless as with no swap case.
There are a few different cases here.
If you NEVER end up scanning or evicting anonymous
pages, scanning them is indeed a waste of time.
However, if you occasionally end pushing something
into swap, it is very useful to know that the pages
that did get pushed to swap had been sitting on the
inactive list for a very long time, and had not been
used in that time.
To limit the amount of wasted work, only SWAP_CLUSTER_MAX
pages are moved from the active_anon list to the inactive_anon
list at a time.
I suppose that could be gated behind a check whether or
not the system has swap space configured, so no anon
pages are ever scanned if the system has no swap space.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-02-26 14:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 17:43 [PATCH 1/5] mm/workingset: remove unused @mapping argument in workingset_eviction() Andrey Ryabinin
2019-02-22 17:43 ` [PATCH 2/5] mm: remove zone_lru_lock() function access ->lru_lock directly Andrey Ryabinin
2019-02-25 12:10 ` Vlastimil Babka
2019-02-22 17:43 ` [PATCH 3/5] mm/compaction: pass pgdat to too_many_isolated() instead of zone Andrey Ryabinin
2019-02-22 19:01 ` Rik van Riel
2019-02-25 12:13 ` Vlastimil Babka
2019-02-22 17:43 ` [PATCH 4/5] mm/vmscan: remove unused lru_pages argument Andrey Ryabinin
2019-02-22 18:02 ` Johannes Weiner
2019-02-25 12:17 ` Vlastimil Babka
2019-02-22 17:43 ` [PATCH 5/5] mm/vmscan: don't forcely shrink active anon lru list Andrey Ryabinin
2019-02-22 18:22 ` Johannes Weiner
2019-02-26 12:04 ` Andrey Ryabinin
2019-02-26 14:42 ` Rik van Riel [this message]
2019-02-22 17:58 ` [PATCH 1/5] mm/workingset: remove unused @mapping argument in workingset_eviction() Johannes Weiner
2019-02-22 19:02 ` Rik van Riel
2019-02-25 12:01 ` Vlastimil Babka
2019-02-26 12:07 ` Andrey Ryabinin
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=63491909d5c7011b946a354000caace11d63cb84.camel@surriel.com \
--to=riel@surriel.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=vbabka@suse.cz \
/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).