From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933391AbcJLXji (ORCPT ); Wed, 12 Oct 2016 19:39:38 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:48567 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932370AbcJLXjh (ORCPT ); Wed, 12 Oct 2016 19:39:37 -0400 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 13 Oct 2016 08:39:01 +0900 From: Minchan Kim To: Michal Hocko , Andrew Morton Cc: Andrew Morton , Mel Gorman , Vlastimil Babka , Joonsoo Kim , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sangseok Lee Subject: Re: [PATCH v3 3/4] mm: try to exhaust highatomic reserve before the OOM Message-ID: <20161012233901.GA30745@bbox> References: <1476259429-18279-1-git-send-email-minchan@kernel.org> <1476259429-18279-4-git-send-email-minchan@kernel.org> <20161012083449.GD17128@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161012083449.GD17128@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michal, On Wed, Oct 12, 2016 at 10:34:50AM +0200, Michal Hocko wrote: > Looks much better. Thanks! I am wondering whether we want to have this > marked for stable. The patch is quite non-intrusive and fires only when > we are really OOM. It is definitely better to try harder than go and > disrupt the system by the OOM killer. So I would add > Fixes: 0aaa29a56e4f ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand") > Cc: stable # 4.4+ Thanks for the information. > > The backport will look slightly different for kernels prior 4.6 because > we do not have should_reclaim_retry yet but the check might hook right > before __alloc_pages_may_oom. As I just got one report and I didn't see similar problem in LKML recently, I didn't mark it to the stable given that patchset size in v1. However, with review, it becomes simple(Thanks, Michal and Vlastimil) and I should admit my ladar is too limited so if you think it's worth, I don't mind. For the stable, {3,4}/4 are must but once we decide, I want to backport all patches {1-4}/4 because without {1,2}, nr_reserved_highatomic mismatch can happen so that unreserve logic doesn't work until force logic is triggered when no_progress_loops is greater than MAX_RECLAIM_RETRIES. It happend very easily in my test. Withtout {1,2}, it works but looks no-good for me. > -- > Michal Hocko > SUSE Labs