From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753760AbdJMGvz (ORCPT ); Fri, 13 Oct 2017 02:51:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:52196 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751551AbdJMGvx (ORCPT ); Fri, 13 Oct 2017 02:51:53 -0400 Date: Fri, 13 Oct 2017 08:51:50 +0200 From: Michal Hocko To: Greg Thelen Cc: Johannes Weiner , Shakeel Butt , Alexander Viro , Vladimir Davydov , Andrew Morton , Linux MM , linux-fsdevel@vger.kernel.org, LKML Subject: Re: [PATCH] fs, mm: account filp and names caches to kmemcg Message-ID: <20171013065150.dzesflih5ot2z3px@dhcp22.suse.cz> References: <20171006075900.icqjx5rr7hctn3zd@dhcp22.suse.cz> <20171009062426.hmqedtqz5hkmhnff@dhcp22.suse.cz> <20171009202613.GA15027@cmpxchg.org> <20171010091430.giflzlayvjblx5bu@dhcp22.suse.cz> <20171010141733.GB16710@cmpxchg.org> <20171010142434.bpiqmsbb7gttrlcb@dhcp22.suse.cz> <20171012190312.GA5075@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 12-10-17 16:57:22, Greg Thelen wrote: [...] > Overcharging kmem with deferred reconciliation sounds good to me. > > A few comments (not reasons to avoid this): > > 1) If a task is moved between memcg it seems possible to overcharge > multiple oom memcg for different kmem/user allocations. > mem_cgroup_oom_synchronize() would see at most one oom memcg in > current->memcg_in_oom. Thus it'd only reconcile a single memcg. But > that seems pretty rare and the next charge to any of the other memcg > would reconcile them. This is a general problem for the cgroup v2 memcg oom handling. > 2) if a kernel thread charges kmem on behalf of a client mm then there > is no good place to call mem_cgroup_oom_synchronize(), short of > launching a work item in mem_cgroup_oom(). I don't we have anything > like that yet. So nothing to worry about. If we do invoke the OOM killer from the charge path, it shouldn't be a problem. > 3) it's debatable if mem_cgroup_oom_synchronize() should first attempt > reclaim before killing. But that's a whole 'nother thread. Again, this shouldn't be an issue if we invoke the oom killer from the charge path. > 4) overcharging with deferred reconciliation could also be used for user > pages. But I haven't looked at the code long enough to know if this > would be a net win. It would solve g-u-p issues failing with ENOMEM unexpectedly just because of memcg charge failure. -- Michal Hocko SUSE Labs