From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757683AbcEDIcO (ORCPT ); Wed, 4 May 2016 04:32:14 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:55776 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993AbcEDIcL (ORCPT ); Wed, 4 May 2016 04:32:11 -0400 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: iamjoonsoo.kim@lge.com X-Original-SENDERIP: 10.177.222.138 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Wed, 4 May 2016 17:32:38 +0900 From: Joonsoo Kim To: Vlastimil Babka Cc: Michal Hocko , Andrew Morton , Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Hillf Danton , linux-mm@kvack.org, LKML Subject: Re: [PATCH 0.14] oom detection rework v6 Message-ID: <20160504083238.GA11859@js1304-P5Q-DELUXE> References: <1461181647-8039-1-git-send-email-mhocko@kernel.org> <20160504054502.GA10899@js1304-P5Q-DELUXE> <5729AEFB.9060101@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5729AEFB.9060101@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 04, 2016 at 10:12:43AM +0200, Vlastimil Babka wrote: > On 05/04/2016 07:45 AM, Joonsoo Kim wrote: > >I still don't agree with some part of this patchset that deal with > >!costly order. As you know, there was two regression reports from Hugh > >and Aaron and you fixed them by ensuring to trigger compaction. I > >think that these show the problem of this patchset. Previous kernel > >doesn't need to ensure to trigger compaction and just works fine in > >any case. > > IIRC previous kernel somehow subtly never OOM'd for !costly orders. IIRC, it would not OOM in thrashing case. But, it could OOM in other cases. > So anything that introduces the possibility of OOM may look like > regression for some corner case workloads. But I don't think that > it's OK to not OOM for e.g. kernel stack allocations? Sorry. Double negation makes me hard to understand since I'm not native. So, you think that it's OK to OOM for kernel stack allocation? I think so, too. But, I want not to OOM prematurely. > >Your series make compaction necessary for all. OOM handling > >is essential part in MM but compaction isn't. OOM handling should not > >depend on compaction. I tested my own benchmark without > >CONFIG_COMPACTION and found that premature OOM happens. > > > >I hope that you try to test something without CONFIG_COMPACTION. > > Hmm a valid point, !CONFIG_COMPACTION should be considered. But > reclaim cannot guarantee forming an order>0 page. But neither does > OOM. So would you suggest we keep reclaiming without OOM as before, > to prevent these regressions? Or where to draw the line here? I suggested that memorizing number of reclaimable pages when entering allocation slowpath and try to reclaim at least that amount. Thrashing is effectively prevented in this algorithm and we don't trigger OOM prematurely. Thanks.