From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753535AbbFAQmj (ORCPT ); Mon, 1 Jun 2015 12:42:39 -0400 Received: from cantor2.suse.de ([195.135.220.15]:38432 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752453AbbFAQmc (ORCPT ); Mon, 1 Jun 2015 12:42:32 -0400 Message-ID: <556C8B75.1030405@suse.cz> Date: Mon, 01 Jun 2015 18:42:29 +0200 From: Vlastimil Babka 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 , Andrew Morton CC: Vladimir Davydov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner Subject: Re: [PATCH] memcg: do not call reclaim if !__GFP_WAIT References: <1432833966-25538-1-git-send-email-vdavydov@parallels.com> <20150528125934.198f57db4c5daf19dd15b184@linux-foundation.org> <20150529065504.GA22728@dhcp22.suse.cz> In-Reply-To: <20150529065504.GA22728@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/29/2015 08:55 AM, Michal Hocko wrote: > On Thu 28-05-15 12:59:34, Andrew Morton wrote: >> On Thu, 28 May 2015 20:26:06 +0300 Vladimir Davydov wrote: >> >> > When trimming memcg consumption excess (see memory.high), we call >> > try_to_free_mem_cgroup_pages without checking if we are allowed to sleep >> > in the current context, which can result in a deadlock. Fix this. >> >> Why does it deadlock? try_to_free_mem_cgroup_pages() is passed the >> gfp_mask and should honour its __GFP_WAIT setting? > > The only instance of __GFP_WAIT check in vmscan code is in zone_reclaim. > Page allocations and memcg reclaim avoids calling reclaim if __GFP_WAIT > is not set. Maybe we can move the check to do_try_to_free_pages? I think it's conceptually wrong. All other paths check it before calling into do_try_to_free_pages() and act appropriately. Here it would potentially mask any atomic-specific fallback strategy. What would make some sense in do_try_to_free_pages() is VM_WARN_ON_ONCE() which however I assume doesn't exist? :)