Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753780AbbH3TC3 (ORCPT ); Sun, 30 Aug 2015 15:02:29 -0400 Received: from mx2.parallels.com ([199.115.105.18]:35956 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753680AbbH3TC2 (ORCPT ); Sun, 30 Aug 2015 15:02:28 -0400 From: Vladimir Davydov To: Andrew Morton CC: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Michal Hocko , Tejun Heo , , Subject: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled Date: Sun, 30 Aug 2015 22:02:16 +0300 Message-ID: X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: US-EXCH.sw.swsoft.com (10.255.249.47) To US-EXCH2.sw.swsoft.com (10.255.249.46) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1116 Lines: 33 Hi, Tejun reported that sometimes memcg/memory.high threshold seems to be silently ignored if kmem accounting is enabled: http://www.spinics.net/lists/linux-mm/msg93613.html It turned out that both SLAB and SLUB try to allocate without __GFP_WAIT first. As a result, if there is enough free pages, memcg reclaim will not get invoked on kmem allocations, which will lead to uncontrollable growth of memory usage no matter what memory.high is set to. This patch set attempts to fix this issue. For more details please see comments to individual patches. Thanks, Vladimir Davydov (2): mm/slab: skip memcg reclaim only if in atomic context mm/slub: do not bypass memcg reclaim for high-order page allocation mm/slab.c | 32 +++++++++++--------------------- mm/slub.c | 24 +++++++++++------------- 2 files changed, 22 insertions(+), 34 deletions(-) -- 2.1.4 -- 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/