Date: Tue, 26 Sep 2017 10:51:27 +0100
From: Mel Gorman <mgorman@techsingularity.net>
To: Hui Zhu <zhuhui@xiaomi.com>
Cc: akpm@linux-foundation.org, mhocko@suse.com, vbabka@suse.cz,
        hillf.zj@alibaba-inc.com, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, teawater@gmail.com
Subject: Re: [RFC 0/2] Use HighAtomic against long-term fragmentation
Message-ID: <20170926095127.p5ocg44et2g62gku@techsingularity.net>
References: <1506415604-4310-1-git-send-email-zhuhui@xiaomi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
In-Reply-To: <1506415604-4310-1-git-send-email-zhuhui@xiaomi.com>
User-Agent: NeoMutt/20170421 (1.8.2)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 957
Lines: 20

On Tue, Sep 26, 2017 at 04:46:42PM +0800, Hui Zhu wrote:
> Current HighAtomic just to handle the high atomic page alloc.
> But I found that use it handle the normal unmovable continuous page
> alloc will help to against long-term fragmentation.
> 

This is not wise. High-order atomic allocations do not always have a
smooth recovery path such as network drivers with large MTUs that have no
choice but to drop the traffic and hope for a retransmit. That's why they
have the highatomic reserve. If the reserve is used for normal unmovable
allocations then allocation requests that could have waited for reclaim
may cause high-order atomic allocations to fail. Changing it may allow
improve latencies in some limited cases while causing functional failures
in others.  If there is a special case where there are a large number of
other high-order allocations then I would suggest increasing min_free_kbytes
instead as a workaround.

-- 
Mel Gorman
SUSE Labs