Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3861340pxu; Mon, 30 Nov 2020 11:48:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJzbw0e4FTwhzfP0VktVZpJQq/69kxJm1P2CT/ATO7S/NRIU1EqJJtKy/jn/3GOx1ALaV7U3 X-Received: by 2002:a50:bb66:: with SMTP id y93mr24313439ede.244.1606765704339; Mon, 30 Nov 2020 11:48:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606765704; cv=none; d=google.com; s=arc-20160816; b=RKmWfkKFJu64qA1D9hEU8zyuIZi5F+MUxwxAXY2ol4Zff6oQY5G7sfUbGfwrI+yqIC OtS7dJXotteQ781TPEGcw6Vn9Zqw+IiJRjhoGKdcqkD6+hfO2CtYlhQ1NPNUCCefctUY t2B5s8XU6cQxyKrigqkbJnOaP+Y9eodh9nuLH+EpCiThKPdnPZpeTOIrYBuX4CQnH4Q2 19Peqc1ALGGaNRNiKJGnM/2RDZU/XLv8eH4j36zwUAb15sbzs+dyIyDJHfO5aZZARuFC qMtopNUGxNjwFnaFz5c29eu7YE2VRTUSorF9PFQ1Ke8/nZxL85PKKvSrHNhMmlEiO712 bAPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=03JMD4RuPYo2VJb6bAXktJHFZqT1yVfytR2jptyT/EA=; b=R6JU/EWl62vIrAuEa/Ou/uGR4Us/AVp9e4u1YVBlffr70SxN/hZ/MkRk/DNsQCj0+l eOakoGU5QVCobuHXhzS+bgt4zSpUdLbzUqNuW/r9yi2ACP0MaP/qWI2r96Ns3QqsnrV7 Rh+Jv0KpXvJ1MXy5GQ90mNIS3J48g2iywpe+0tX+6BPLM3zCqtpRJpdI0QkZstXEELTP YIo4ZhuRmknaTmQAzoyXnYks4pa/Aek4fFDpM7g7JOtLzcdmV6WbY2ujy10N1226ZNQ8 mJwKGQGOnRarQ9/usk3LfX+BkbJkOHeolMqPzI5gqv3Ny8PR8PoQLYAwEer3kuSknDD6 p9EA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e0kz8S6O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bi20si11486309ejb.366.2020.11.30.11.48.01; Mon, 30 Nov 2020 11:48:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e0kz8S6O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728990AbgK3TpB (ORCPT + 99 others); Mon, 30 Nov 2020 14:45:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727952AbgK3TpB (ORCPT ); Mon, 30 Nov 2020 14:45:01 -0500 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BD29C0613D2 for ; Mon, 30 Nov 2020 11:44:15 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id f24so19800733ljk.13 for ; Mon, 30 Nov 2020 11:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=03JMD4RuPYo2VJb6bAXktJHFZqT1yVfytR2jptyT/EA=; b=e0kz8S6OUqevvE2bK0NlyDBFDx5jpi7V+mSO6Uh8N4AW3Ennxjkrh/bUj1wGBa7Lkv vrsyR2ei7/leHTKwsK6eft74lJ6QLL2uUrtFrKzzDdjZgP/jAmqmm3lErmYqYdVL9mMA 61tv8UFhfkXncMH+z+KYB0rXUVUreZ4098CUanQCeh91bMuoDIcUNWZTVEdIROsVkxPx C2EWrggTsn0H4UYe9QkQn6h8PqtPbOZSMKWf+NpUMSqlk32BEuCQeYLFRlBQb7EgxpvO OETRqxuBZrG55uBQNnkYf2De95FkANtGoy2/QiWePHhM8ePOro4FmJA9hVI+j1j/8ks/ NhMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=03JMD4RuPYo2VJb6bAXktJHFZqT1yVfytR2jptyT/EA=; b=Or+GljWFaSxrpJUWC4gkdE9hLl+7UIp8EBdMtuB/dR7SObCLcHFwVVz1sHQbWkki+1 ZkuvCRtYYexZZbQOZDdvN3mL6+9AvDe1wVA6miKUNkIyRTKMNmVjQuIz1ao2YQtuAsEm hWZ7ZXjGhTOfZsDKWSD89eg4Ps9zfMxhEvnq43WkHcNfEie7jYDh5NHriK1O0DK2lOF5 1N06slltt7ZgHy1Vw8UtQI4PploBtjPawU4GKWoRvnkaBrNL6P8c5/bKuHjZ8aSKqjYS g6ujZW5/Flen7Vt+nkG5Lz3IpMdkMBmYQZ4onDh6VjQrbg+WXQrnE3Xa/n7y/I5o3eZ7 8H9w== X-Gm-Message-State: AOAM533e1EcPxRiivfmDan4MeACmEKPOjFreyyWKaOwT+BYU3NhqI4hG 1jYrOzXLgsZzpP8vSrfRPXk= X-Received: by 2002:a2e:9cd3:: with SMTP id g19mr10564527ljj.188.1606765453562; Mon, 30 Nov 2020 11:44:13 -0800 (PST) Received: from [192.168.2.145] (109-252-193-159.dynamic.spd-mgts.ru. [109.252.193.159]) by smtp.googlemail.com with ESMTPSA id f20sm239205lfk.230.2020.11.30.11.44.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Nov 2020 11:44:12 -0800 (PST) Subject: Re: [PATCH] mm/memcg: bail out early when !memcg in mem_cgroup_lruvec To: Alex Shi , Andrew Morton Cc: Johannes Weiner , Shakeel Butt , Roman Gushchin , Lorenzo Stoakes , Stephen Rothwell , Alexander Duyck , Yafang Shao , Wei Yang , linux-kernel@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" References: <1606446515-36069-1-git-send-email-alex.shi@linux.alibaba.com> <20201127200215.dc96a839cdd816361e7093e6@linux-foundation.org> <9ddb17cd-cf5f-15b1-6a7d-986ee44fd5df@linux.alibaba.com> From: Dmitry Osipenko Message-ID: <67aacbba-7049-bee8-0ad4-ab4db588c841@gmail.com> Date: Mon, 30 Nov 2020 22:44:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <9ddb17cd-cf5f-15b1-6a7d-986ee44fd5df@linux.alibaba.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 29.11.2020 07:43, Alex Shi пишет: > > > 在 2020/11/28 下午12:02, Andrew Morton 写道: >> On Fri, 27 Nov 2020 11:08:35 +0800 Alex Shi wrote: >> >>> Sometime, we use NULL memcg in mem_cgroup_lruvec(memcg, pgdat) >>> so we could get out early in the situation to avoid useless checking. >>> >>> Also warning if both parameter are NULL. >> >> Why do you think a warning is needed here? > > Uh, Consider there are no problem for long time, it could be saved. > >> >>> --- a/include/linux/memcontrol.h >>> +++ b/include/linux/memcontrol.h >>> @@ -613,14 +613,13 @@ static inline struct lruvec *mem_cgroup_lruvec(struct mem_cgroup *memcg, >>> struct mem_cgroup_per_node *mz; >>> struct lruvec *lruvec; >>> >>> - if (mem_cgroup_disabled()) { >>> + VM_WARN_ON_ONCE(!memcg && !pgdat); >>> + >>> + if (mem_cgroup_disabled() || !memcg) { >>> lruvec = &pgdat->__lruvec; >>> goto out; >>> } >>> >>> - if (!memcg) >>> - memcg = root_mem_cgroup; >>> - >> >> This change isn't obviously equivalent, is it? > > If !memcg, the root_mem_cgroup will still lead the lruvec to a pgdat > same as parameter. > >> >>> mz = mem_cgroup_nodeinfo(memcg, pgdat->node_id); >>> lruvec = &mz->lruvec; >>> out: >> >> And the resulting code is awkward: >> >> if (mem_cgroup_disabled() || !memcg) { >> lruvec = &pgdat->__lruvec; >> goto out; >> } >> >> mz = mem_cgroup_nodeinfo(memcg, pgdat->node_id); >> lruvec = &mz->lruvec; >> out: >> >> >> could be >> >> if (mem_cgroup_disabled() || !memcg) { >> lruvec = &pgdat->__lruvec; >> } else { >> mem_cgroup_per_node mz; >> >> mz = mem_cgroup_nodeinfo(memcg, pgdat->node_id); >> lruvec = &mz->lruvec; >> } >> > > Right. remove 'goto' is better for understander. > > So, is the following patch ok? > > From 225f29e03b40a7cbaeb4e3bb76f8efbcd7d648a2 Mon Sep 17 00:00:00 2001 > From: Alex Shi > Date: Wed, 25 Nov 2020 14:06:33 +0800 > Subject: [PATCH v2] mm/memcg: bail out early when !memcg in mem_cgroup_lruvec > > Sometime, we use NULL memcg in mem_cgroup_lruvec(memcg, pgdat) > so we could get out early in the situation to avoid useless checking. > > Polished as Andrew Morton's suggestion. > > Signed-off-by: Alex Shi > Cc: Andrew Morton > Cc: Johannes Weiner > Cc: Shakeel Butt > Cc: Roman Gushchin > Cc: Lorenzo Stoakes > Cc: Stephen Rothwell > Cc: Alexander Duyck > Cc: Yafang Shao > Cc: Wei Yang > Cc: linux-kernel@vger.kernel.org > --- > include/linux/memcontrol.h | 15 ++++++--------- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 3e6a1df3bdb9..4ff2ffe2b73d 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -610,20 +610,17 @@ mem_cgroup_nodeinfo(struct mem_cgroup *memcg, int nid) > static inline struct lruvec *mem_cgroup_lruvec(struct mem_cgroup *memcg, > struct pglist_data *pgdat) > { > - struct mem_cgroup_per_node *mz; > struct lruvec *lruvec; > > - if (mem_cgroup_disabled()) { > + if (mem_cgroup_disabled() || !memcg) { > lruvec = &pgdat->__lruvec; > - goto out; > - } > + } else { > + struct mem_cgroup_per_node *mz; > > - if (!memcg) > - memcg = root_mem_cgroup; > + mz = mem_cgroup_nodeinfo(memcg, pgdat->node_id); > + lruvec = &mz->lruvec; > + } > > - mz = mem_cgroup_nodeinfo(memcg, pgdat->node_id); > - lruvec = &mz->lruvec; > -out: > /* > * Since a node can be onlined after the mem_cgroup was created, > * we have to be prepared to initialize lruvec->pgdat here; > Hi, This patch causes a hard lock on one of my ARM32 devices using today's linux-next, please fix.