Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753036AbcCKNp4 (ORCPT ); Fri, 11 Mar 2016 08:45:56 -0500 Received: from mx2.parallels.com ([199.115.105.18]:46595 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752735AbcCKNpt (ORCPT ); Fri, 11 Mar 2016 08:45:49 -0500 Date: Fri, 11 Mar 2016 16:45:34 +0300 From: Vladimir Davydov To: Michal Hocko CC: Andrew Morton , Johannes Weiner , , Subject: Re: [PATCH] mm: memcontrol: zap task_struct->memcg_oom_{gfp_mask,order} Message-ID: <20160311134533.GN1946@esperanza> References: <1457691167-22756-1-git-send-email-vdavydov@virtuozzo.com> <20160311115450.GH27701@dhcp22.suse.cz> <20160311123900.GM1946@esperanza> <20160311125104.GM27701@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20160311125104.GM27701@dhcp22.suse.cz> X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) 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: 1665 Lines: 38 On Fri, Mar 11, 2016 at 01:51:05PM +0100, Michal Hocko wrote: > On Fri 11-03-16 15:39:00, Vladimir Davydov wrote: > > On Fri, Mar 11, 2016 at 12:54:50PM +0100, Michal Hocko wrote: > > > On Fri 11-03-16 13:12:47, Vladimir Davydov wrote: > > > > These fields are used for dumping info about allocation that triggered > > > > OOM. For cgroup this information doesn't make much sense, because OOM > > > > killer is always invoked from page fault handler. > > > > > > The oom killer is indeed invoked in a different context but why printing > > > the original mask and order doesn't make any sense? Doesn't it help to > > > see that the reclaim has failed because of GFP_NOFS? > > > > I don't see how this can be helpful. How would you use it? > > If we start seeing GFP_NOFS triggered OOMs we might be enforced to > rethink our current strategy to ignore this charge context for OOM. IMO the fact that a lot of OOMs are triggered by GFP_NOFS allocations can't be a good enough reason to reconsider OOM strategy. We need to know what kind of allocation fails anyway, and the current OOM dump gives us no clue about that. Besides, what if OOM was triggered by GFP_NOFS by pure chance, i.e. it would have been triggered by GFP_KERNEL if it had happened at that time? IMO it's just confusing. > > > Wouldn't it be better to print err msg in try_charge anyway? > > Wouldn't that lead to excessive amount of logged messages? We could ratelimit these messages. Slab charge failures are already reported to dmesg (see ___slab_alloc -> slab_out_of_memory) and nobody's complained so far. Are there any non-slab GFP_NOFS allocations charged to memcg? Thanks, Vladimir