From: Robert Harris <robert.m.harris@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Kemi Wang <kemi.wang@intel.com>,
David Rientjes <rientjes@google.com>,
Yafang Shao <laoar.shao@gmail.com>,
Kangmin Park <l4stpr0gr4m@gmail.com>,
Mel Gorman <mgorman@suse.de>,
Yisheng Xie <xieyisheng1@huawei.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Huang Ying <ying.huang@intel.com>,
Vinayak Menon <vinmenon@codeaurora.org>
Subject: Re: [PATCH 1/1] mm, compaction: correct the bounds of __fragmentation_index()
Date: Mon, 19 Feb 2018 12:14:26 +0000 [thread overview]
Message-ID: <E718672A-91A0-4A5A-91B5-A6CF1E9BD544@oracle.com> (raw)
In-Reply-To: <20180219082649.GD21134@dhcp22.suse.cz>
> On 19 Feb 2018, at 08:26, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sun 18-02-18 16:47:55, robert.m.harris@oracle.com wrote:
>> From: "Robert M. Harris" <robert.m.harris@oracle.com>
>>
>> __fragmentation_index() calculates a value used to determine whether
>> compaction should be favoured over page reclaim in the event of allocation
>> failure. The calculation itself is opaque and, on inspection, does not
>> match its existing description. The function purports to return a value
>> between 0 and 1000, representing units of 1/1000. Barring the case of a
>> pathological shortfall of memory, the lower bound is instead 500. This is
>> significant because it is the default value of sysctl_extfrag_threshold,
>> i.e. the value below which compaction should be avoided in favour of page
>> reclaim for costly pages.
>>
>> This patch implements and documents a modified version of the original
>> expression that returns a value in the range 0 <= index < 1000. It amends
>> the default value of sysctl_extfrag_threshold to preserve the existing
>> behaviour.
>
> It is not really clear to me what is the actual problem you are trying
> to solve by this patch. Is there any bug or are you just trying to
> improve the current implementation to be more effective?
There is not a significant bug.
The first problem is that the mathematical expression in
__fragmentation_index() is opaque, particularly given the lack of
description in the comments or the original commit message. This patch
provides such a description.
Simply annotating the expression did not make sense since the formula
doesn't work as advertised. The fragmentation index is described as
being in the range 0 to 1000 but the bounds of the formula are instead
500 to 1000. This patch changes the formula so that its lower bound is
0.
The fragmentation index is compared to the tuneable
sysctl_extfrag_threshold, which defaults to 500. If the index is above
this value then compaction is preferred over page reclaim in the event
of allocation failure. Given the issue above, the index will almost
always exceed the default threshold and compaction will occur even if
there is low fragmentation. This patch changes the default value of the
tuneable to 0, meaning that the existing behaviour will be unchanged.
Changing sysctl_extfrag_threshold back to something non-zero in a future
patch would effect the behaviour intended by the original code but would
require more comprehensive testing since it would modify the kernel's
performance under memory pressure.
Robert Harris
--
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>
next prev parent reply other threads:[~2018-02-19 12:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-18 16:47 [PATCH 0/1] " robert.m.harris
2018-02-18 16:47 ` [PATCH 1/1] " robert.m.harris
2018-02-19 8:26 ` Michal Hocko
2018-02-19 12:14 ` Robert Harris [this message]
2018-02-19 12:39 ` Michal Hocko
2018-02-19 14:30 ` Robert Harris
2018-02-23 9:10 ` Michal Hocko
2018-02-23 13:40 ` Robert Harris
2018-02-23 13:52 ` Michal Hocko
2018-02-19 9:47 ` Mel Gorman
2018-02-19 12:26 ` Robert Harris
2018-02-19 13:10 ` Mel Gorman
2018-02-19 14:37 ` Robert Harris
2018-02-19 8:24 ` [PATCH 0/1] " Michal Hocko
2018-02-19 11:40 ` Robert Harris
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=E718672A-91A0-4A5A-91B5-A6CF1E9BD544@oracle.com \
--to=robert.m.harris@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dave@stgolabs.net \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=kemi.wang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=l4stpr0gr4m@gmail.com \
--cc=laoar.shao@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=vinmenon@codeaurora.org \
--cc=xieyisheng1@huawei.com \
--cc=ying.huang@intel.com \
/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