Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965087AbbD0TGh (ORCPT ); Mon, 27 Apr 2015 15:06:37 -0400 Received: from gum.cmpxchg.org ([85.214.110.215]:47285 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964936AbbD0TGb (ORCPT ); Mon, 27 Apr 2015 15:06:31 -0400 From: Johannes Weiner To: Andrew Morton Cc: Michal Hocko , Tetsuo Handa , Andrea Arcangeli , Dave Chinner , David Rientjes , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/9] mm: improve OOM mechanism v2 Date: Mon, 27 Apr 2015 15:05:46 -0400 Message-Id: <1430161555-6058-1-git-send-email-hannes@cmpxchg.org> X-Mailer: git-send-email 2.3.6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1562 Lines: 30 There is a possible deadlock scenario between the page allocator and the OOM killer. Most allocations currently retry forever inside the page allocator, but when the OOM killer is invoked the chosen victim might try taking locks held by the allocating task. This series, on top of many cleanups in the allocator & OOM killer, grants such OOM- killing allocations access to the system's memory reserves in order for them to make progress without relying on their own kill to exit. Changes since v1: - drop GFP_NOFS deadlock fix (Dave Chinner) - drop low-order deadlock fix (Michal Hocko) - fix missing oom_lock in sysrq+f (Michal Hocko) - fix PAGE_ALLOC_COSTLY retry condition (Michal Hocko) - ALLOC_NO_WATERMARKS only for OOM victims, not all killed tasks (Tetsuo Handa) - bump OOM wait timeout from 1s to 5s (Vlastimil Babka & Michal Hocko) drivers/staging/android/lowmemorykiller.c | 2 +- drivers/tty/sysrq.c | 2 + include/linux/oom.h | 12 +- kernel/exit.c | 2 +- mm/memcontrol.c | 20 ++-- mm/oom_kill.c | 167 +++++++--------------------- mm/page_alloc.c | 161 ++++++++++++--------------- 7 files changed, 137 insertions(+), 229 deletions(-) -- 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/