Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4411937imm; Wed, 30 May 2018 05:18:28 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJGVc6tpKL/XyESG1BXaHpcRlVZJPp2MfrA6n+7TXbxBfAVqxqsLtB3a2TtVwBGDrJ2+3ET X-Received: by 2002:a62:fc8d:: with SMTP id e135-v6mr2590165pfh.208.1527682708060; Wed, 30 May 2018 05:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527682708; cv=none; d=google.com; s=arc-20160816; b=U91Kq8x5naAaZpYdYSsQlut5JYBjSKtvn6VQdq2+YM1uv44CDQL6KKUkUwL4jeJhH0 +5N3gleyhNyGbmCSBWsTg1/2LotmsV9VIOQ9lu/gitjQQVdvpQndWMYqeZIc+zFl/A+S gUW1rwe3qK7mQh5819vlsQQmIqSJS11CHBGbI9e4jVCUY+Va8urwOO1eGUFYCGai324j Dvhg2x1GkEwPHhuRYWq+MzqDPmhdjLuA4uwmkQaGSUzpk7Awd538TNxxdXkyxUsI+i7q Lc6Gtm+YPmArhhCmUG8YmdUV1CqGwrjwOizDxdMV25vtOFOGf3aIUI/KpNzLrsQGnlwV TZaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=1vhSzBMkXdKL2V3dd9CtOiN2ICxtb9XpM0ZMTL5hRoM=; b=uYiZ/rPNPcmhLiW7hirLGteZ84Ygx5ZFIeE8cXlQfZBgGaUvMcMRzpaAMtEbIAmqK/ ay0NmPDvFHT3q8eq3w3Dxv0mFjBLKiStxSh5niwqlOSzQPv1IjDt/B9UAPOIWtQtE+6B AWW+s4oQeN55iioHAyxln/+7vnf6DaDYJsBwb2c4fAUjjxPQcLBX1dBPloer75ckjuoK BvLMlDQIcGJGkdB1K/ClqDW9JmrWZ1X6jkEfMx7oD+ewGi9YErqxa0zu4rYWMfY9+/GS FFxEtzBT1bkl/Ru77DhwaLAU8SAMP1k3vsXjOPdXBls5R2d28MFv1PozljrhTypWwnQ0 EKMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s14-v6si33767317pfh.11.2018.05.30.05.18.13; Wed, 30 May 2018 05:18:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753109AbeE3MR3 (ORCPT + 99 others); Wed, 30 May 2018 08:17:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:43286 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751844AbeE3MRY (ORCPT ); Wed, 30 May 2018 08:17:24 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2579BAD21; Wed, 30 May 2018 12:17:23 +0000 (UTC) Date: Wed, 30 May 2018 14:17:21 +0200 From: Michal Hocko To: Andrew Morton Cc: "Eric W. Biederman" , Johannes Weiner , Kirill Tkhai , peterz@infradead.org, viro@zeniv.linux.org.uk, mingo@kernel.org, paulmck@linux.vnet.ibm.com, keescook@chromium.org, riel@redhat.com, tglx@linutronix.de, kirill.shutemov@linux.intel.com, marcos.souza.org@gmail.com, hoeun.ryu@gmail.com, pasha.tatashin@oracle.com, gs051095@gmail.com, dhowells@redhat.com, rppt@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, Balbir Singh , Tejun Heo , Oleg Nesterov Subject: Re: [PATCH 0/2] mm->owner to mm->memcg fixes Message-ID: <20180530121721.GD27180@dhcp22.suse.cz> References: <20180504145435.GA26573@redhat.com> <87y3gzfmjt.fsf@xmission.com> <20180504162209.GB26573@redhat.com> <871serfk77.fsf@xmission.com> <87tvrncoyc.fsf_-_@xmission.com> <20180510121418.GD5325@dhcp22.suse.cz> <20180522125757.GL20020@dhcp22.suse.cz> <87wovu889o.fsf@xmission.com> <20180524111002.GB20441@dhcp22.suse.cz> <20180524141635.c99b7025a73a709e179f92a2@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180524141635.c99b7025a73a709e179f92a2@linux-foundation.org> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 24-05-18 14:16:35, Andrew Morton wrote: > On Thu, 24 May 2018 13:10:02 +0200 Michal Hocko wrote: > > > I would really prefer and appreciate a repost with all the fixes folded > > in. > > [1/2] Thanks Andrew and sorry it took so long! This seems to be missing the fix for the issue I've mentioned in http://lkml.kernel.org/r/20180510121838.GE5325@dhcp22.suse.cz and Eric wanted to handle by http://lkml.kernel.org/r/87wovu889o.fsf@xmission.com. I do not think that this fix is really correct one though. I will comment in a reply to that email. In any case I really think this should better be reposted in one patch series and restart the discussion. I strongly suggest revisiting my previous attempt http://lkml.kernel.org/r/1436358472-29137-8-git-send-email-mhocko@kernel.org including the follow up discussion regarding the unfortunate CLONE_VM outside of thread group case and potential solution for that. > -static void mm_init_owner(struct mm_struct *mm, struct task_struct *p) > +static void mm_init_memcg(struct mm_struct *mm) > { > #ifdef CONFIG_MEMCG > - mm->owner = p; > + struct cgroup_subsys_state *css; > + > + /* Ensure mm->memcg is initialized */ > + mm->memcg = NULL; > + > + rcu_read_lock(); > + css = task_css(current, memory_cgrp_id); > + if (css && css_tryget(css)) > + mm_update_memcg(mm, mem_cgroup_from_css(css)); > + rcu_read_unlock(); Is it possible that css_tryget ever fails here? I remember I used to do plain css_get in my patch. > @@ -4850,15 +4836,16 @@ static int mem_cgroup_can_attach(struct > if (!move_flags) > return 0; > > - from = mem_cgroup_from_task(p); > + from = mem_cgroup_from_css(task_css(p, memory_cgrp_id)); > > VM_BUG_ON(from == memcg); > > mm = get_task_mm(p); > if (!mm) > return 0; > - /* We move charges only when we move a owner of the mm */ > - if (mm->owner == p) { > + > + /* We move charges except for creative uses of CLONE_VM */ > + if (mm->memcg == from) { I must be missing something here but how do you prevent those cases? AFAICS processes sharing the mm will simply allow to migrate. > VM_BUG_ON(mc.from); > VM_BUG_ON(mc.to); > VM_BUG_ON(mc.precharge); Other than that the patch makes sense to me. -- Michal Hocko SUSE Labs