[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161011065341.GC31996@dhcp22.suse.cz>
Date: Tue, 11 Oct 2016 08:53:41 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Minchan Kim <minchan@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...hsingularity.net>,
Vlastimil Babka <vbabka@...e.cz>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Sangseok Lee <sangseok.lee@....com>
Subject: Re: [PATCH 0/4] use up highorder free pages before OOM
On Tue 11-10-16 14:06:43, Minchan Kim wrote:
> On Mon, Oct 10, 2016 at 09:47:31AM +0200, Michal Hocko wrote:
[...]
> > that close to OOM usually blows up later or starts trashing very soon.
> > It is true that a particular workload might benefit from ever last
> > allocatable page in the system but it would be better to mention all
> > that in the changelog.
>
> I don't unerstand what phrase you really want to include the changelog.
> I will add the information which isolate 30M free pages before 4K page
> allocation failure in next version. If you want something to add,
> please say again.
Describe your usecase where the additional 1% of memory can allow a
sustainable workload without OOM. This is not usually the case as I've
tried to explain but it is true that the compression might change the
picture somehow. If your testcase is artificial, try to explain how it
emulates a real workload etc...
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists