From patchwork Wed Mar 25 06:17:14 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Weiner X-Patchwork-Id: 6088431 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 2DEE6BF90F for ; Wed, 25 Mar 2015 06:18:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3DDCE200E8 for ; Wed, 25 Mar 2015 06:18:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 31D692034E for ; Wed, 25 Mar 2015 06:18:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752667AbbCYGRw (ORCPT ); Wed, 25 Mar 2015 02:17:52 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:50905 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752634AbbCYGRu (ORCPT ); Wed, 25 Mar 2015 02:17:50 -0400 From: Johannes Weiner To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Linus Torvalds , Andrew Morton , Tetsuo Handa , Huang Ying , Andrea Arcangeli , Dave Chinner , Michal Hocko , Theodore Ts'o Subject: [patch 10/12] mm: page_alloc: emergency reserve access for __GFP_NOFAIL allocations Date: Wed, 25 Mar 2015 02:17:14 -0400 Message-Id: <1427264236-17249-11-git-send-email-hannes@cmpxchg.org> X-Mailer: git-send-email 2.3.3 In-Reply-To: <1427264236-17249-1-git-send-email-hannes@cmpxchg.org> References: <1427264236-17249-1-git-send-email-hannes@cmpxchg.org> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP __GFP_NOFAIL allocations can deadlock the OOM killer when they're holding locks that the OOM victim might need to exit. When that happens the allocation may never complete, which has disastrous effects on things like in-flight filesystem transactions. When the system is OOM, allow __GFP_NOFAIL allocations to dip into the emergency reserves in the hope that this will allow transactions and writeback to complete and the deadlock can be avoided. Signed-off-by: Johannes Weiner Suggested-by: Andrea Arcangeli Acked-by: Michal Hocko --- mm/page_alloc.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 3c165016175d..832ad1c7cd4f 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2403,9 +2403,17 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, int alloc_flags, * from exiting. While allocations can use OOM kills to free * memory, they can not necessarily rely on their *own* kills * to make forward progress. + * + * This last point is crucial for __GFP_NOFAIL allocations. + * Since they can't quit, they might actually deadlock, so + * give them hail mary access to the emergency reserves. */ - alloc_flags &= ~ALLOC_WMARK_MASK; - alloc_flags |= ALLOC_WMARK_OOM; + if (gfp_mask & __GFP_NOFAIL) { + alloc_flags |= ALLOC_NO_WATERMARKS; + } else { + alloc_flags &= ~ALLOC_WMARK_MASK; + alloc_flags |= ALLOC_WMARK_OOM; + } out: mutex_unlock(&oom_lock); alloc: