From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38D61C433E0 for ; Thu, 14 May 2020 01:16:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A45020693 for ; Thu, 14 May 2020 01:16:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A45020693 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6170380047; Wed, 13 May 2020 21:16:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C88D8003E; Wed, 13 May 2020 21:16:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DD8980047; Wed, 13 May 2020 21:16:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 33B5F8003E for ; Wed, 13 May 2020 21:16:39 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E2CD02C0C for ; Thu, 14 May 2020 01:16:38 +0000 (UTC) X-FDA: 76813559676.05.legs64_914496fab8a03 X-HE-Tag: legs64_914496fab8a03 X-Filterd-Recvd-Size: 3259 Received: from huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 May 2020 01:16:38 +0000 (UTC) Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B7404DF910A9E833359C; Thu, 14 May 2020 09:16:34 +0800 (CST) Received: from [10.133.206.78] (10.133.206.78) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 14 May 2020 09:16:29 +0800 Subject: Re: [PATCH v2] memcg: Fix memcg_kmem_bypass() for remote memcg charging To: Roman Gushchin CC: Michal Hocko , Johannes Weiner , Vladimir Davydov , Cgroups , , Andrew Morton , Shakeel Butt References: <20200513090502.GV29153@dhcp22.suse.cz> <76f71776-d049-7407-8574-86b6e9d80704@huawei.com> <20200513112905.GX29153@dhcp22.suse.cz> <3a721f62-5a66-8bc5-247b-5c8b7c51c555@huawei.com> <20200513161110.GA70427@carbon.DHCP.thefacebook.com> From: Zefan Li Message-ID: <20e89344-cf00-8b0c-64c3-0ac7efd601e6@huawei.com> Date: Thu, 14 May 2020 09:16:29 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20200513161110.GA70427@carbon.DHCP.thefacebook.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.133.206.78] X-CFilter-Loop: Reflected X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2020/5/14 0:11, Roman Gushchin wrote: > On Wed, May 13, 2020 at 07:47:49PM +0800, Zefan Li wrote: >> While trying to use remote memcg charging in an out-of-tree kernel module >> I found it's not working, because the current thread is a workqueue thread. >> >> As we will probably encounter this issue in the future as the users of >> memalloc_use_memcg() grow, it's better we fix it now. >> >> Signed-off-by: Zefan Li >> --- >> >> v2: add a comment as sugguested by Michal. and add changelog to explain why >> upstream kernel needs this fix. >> >> --- >> >> mm/memcontrol.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index a3b97f1..43a12ed 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2802,6 +2802,9 @@ static void memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg, >> >> static inline bool memcg_kmem_bypass(void) >> { >> + /* Allow remote memcg charging in kthread contexts. */ >> + if (unlikely(current->active_memcg)) >> + return false; >> if (in_interrupt() || !current->mm || (current->flags & PF_KTHREAD)) >> return true; > > Shakeel is right about interrupts. How about something like this? > > static inline bool memcg_kmem_bypass(void) > { > if (in_interrupt()) > return true; > > if ((!current->mm || current->flags & PF_KTHREAD) && !current->active_memcg) > return true; > > return false; > } > I thought the user should ensure not do this, but now I think it makes sense to just bypass the interrupt case. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zefan Li Subject: Re: [PATCH v2] memcg: Fix memcg_kmem_bypass() for remote memcg charging Date: Thu, 14 May 2020 09:16:29 +0800 Message-ID: <20e89344-cf00-8b0c-64c3-0ac7efd601e6@huawei.com> References: <20200513090502.GV29153@dhcp22.suse.cz> <76f71776-d049-7407-8574-86b6e9d80704@huawei.com> <20200513112905.GX29153@dhcp22.suse.cz> <3a721f62-5a66-8bc5-247b-5c8b7c51c555@huawei.com> <20200513161110.GA70427@carbon.DHCP.thefacebook.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200513161110.GA70427-lLJQVQxiE4uLfgCeKHXN1g2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Roman Gushchin Cc: Michal Hocko , Johannes Weiner , Vladimir Davydov , Cgroups , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Andrew Morton , Shakeel Butt On 2020/5/14 0:11, Roman Gushchin wrote: > On Wed, May 13, 2020 at 07:47:49PM +0800, Zefan Li wrote: >> While trying to use remote memcg charging in an out-of-tree kernel module >> I found it's not working, because the current thread is a workqueue thread. >> >> As we will probably encounter this issue in the future as the users of >> memalloc_use_memcg() grow, it's better we fix it now. >> >> Signed-off-by: Zefan Li >> --- >> >> v2: add a comment as sugguested by Michal. and add changelog to explain why >> upstream kernel needs this fix. >> >> --- >> >> mm/memcontrol.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/mm/memcontrol.c b/mm/memcontrol.c >> index a3b97f1..43a12ed 100644 >> --- a/mm/memcontrol.c >> +++ b/mm/memcontrol.c >> @@ -2802,6 +2802,9 @@ static void memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg, >> >> static inline bool memcg_kmem_bypass(void) >> { >> + /* Allow remote memcg charging in kthread contexts. */ >> + if (unlikely(current->active_memcg)) >> + return false; >> if (in_interrupt() || !current->mm || (current->flags & PF_KTHREAD)) >> return true; > > Shakeel is right about interrupts. How about something like this? > > static inline bool memcg_kmem_bypass(void) > { > if (in_interrupt()) > return true; > > if ((!current->mm || current->flags & PF_KTHREAD) && !current->active_memcg) > return true; > > return false; > } > I thought the user should ensure not do this, but now I think it makes sense to just bypass the interrupt case.