Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754340AbbGAOas (ORCPT ); Wed, 1 Jul 2015 10:30:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39949 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752103AbbGAOap (ORCPT ); Wed, 1 Jul 2015 10:30:45 -0400 Message-ID: <5593F98C.4010406@redhat.com> Date: Wed, 01 Jul 2015 10:30:36 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michal Hocko , Nikolay Borisov , Johannes Weiner , Andrew Morton CC: Dave Chinner , "Theodore Ts'o" , Marian Marinov , Hugh Dickins , linux-mm@kvack.org, LKML , linux-ext4@vger.kernel.org Subject: Re: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS allocations References: <1435677437-16717-1-git-send-email-mhocko@suse.cz> <20150701061731.GB6286@dhcp22.suse.cz> <20150701133715.GA6287@dhcp22.suse.cz> In-Reply-To: <20150701133715.GA6287@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1630 Lines: 35 On 07/01/2015 09:37 AM, Michal Hocko wrote: > Fix this issue by limiting the wait to reclaim triggered by __GFP_FS > allocations to make sure we are not called from filesystem paths which > might be doing exactly this kind of IO optimizations. The page fault > path, which is the only path that triggers memcg oom killer since 3.12, > shouldn't require GFP_NOFS and so we shouldn't reintroduce the premature > OOM killer issue which was originally addressed by the heuristic. > > As per David Chinner the xfs is doing similar thing since 2.6.15 already > so ext4 is not the only affected filesystem. Moreover he notes: > : For example: IO completion might require unwritten extent conversion > : which executes filesystem transactions and GFP_NOFS allocations. The > : writeback flag on the pages can not be cleared until unwritten > : extent conversion completes. Hence memory reclaim cannot wait on > : page writeback to complete in GFP_NOFS context because it is not > : safe to do so, memcg reclaim or otherwise. I remember fixing something like this back in the 2.2 days. Funny how these bugs keep coming back. > Cc: stable # 3.6+ > Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages") > Reported-by: Nikolay Borisov > Signed-off-by: Michal Hocko Reviewed-by: Rik van Riel -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/