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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A5FAEB64DC for ; Fri, 7 Jul 2023 02:38:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6AC08D0002; Thu, 6 Jul 2023 22:38:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF3418D0001; Thu, 6 Jul 2023 22:38:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B93FA8D0002; Thu, 6 Jul 2023 22:38:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A6B1F8D0001 for ; Thu, 6 Jul 2023 22:38:37 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4D75CC09BF for ; Fri, 7 Jul 2023 02:38:37 +0000 (UTC) X-FDA: 80983257474.19.789DE5A Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf22.hostedemail.com (Postfix) with ESMTP id 3C617C000A for ; Fri, 7 Jul 2023 02:38:32 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688697514; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=59VY5065j3WU9COMTzmTDAq3LQWxK25XJgHQS7opfG8=; b=L/CTbg4hN/fWjzl5+IHK8cTIIG97dlvGOCkA1+xBAs6eNTyoYCdKiUM2Ay64oCCXtZrLyQ 1TyYRqCdza2wwIz4D9+vw2edJvJoHeQKI9l0Di1IpPIbKki64ZiOAaFiplQMAVRtDTy2/K tZQb6tTUZVRojgvMzFOLesn1ytOSOro= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688697514; a=rsa-sha256; cv=none; b=RXgrf/sT0y+kK8SSNZCmqhpKOCsjUabFWgfjH6LpbzSeg5ItIDqnFF9DWQjgbG3doE25IJ JlDcRtJChr7VNxLBXwpD6pLBbwo7IWx9615M6fDaObCrnenrgjfhyJseSD8dfFW7WhZp7U DD30Spv0dxSANLoYyhuUGRN6R6uj1Xk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from canpemm500002.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QxyDL0rryzMqMl; Fri, 7 Jul 2023 10:35:14 +0800 (CST) Received: from [10.174.151.185] (10.174.151.185) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 7 Jul 2023 10:38:28 +0800 Subject: Re: [PATCH] mm/memcg: remove definition of MEM_CGROUP_ID_MAX when !CONFIG_MEMCG To: Muchun Song CC: Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , , LKML , Linux Memory Management List References: <20230706112820.2393447-1-linmiaohe@huawei.com> <892B507C-CFE8-4792-BA5F-3C698290A8EE@linux.dev> <61ce2910-f3de-cfb7-bdd3-546ade0cb6f3@huawei.com> <52C942A9-29F7-473F-8674-6CB584F009BA@linux.dev> From: Miaohe Lin Message-ID: Date: Fri, 7 Jul 2023 10:38:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <52C942A9-29F7-473F-8674-6CB584F009BA@linux.dev> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.151.185] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 3C617C000A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: stpr9nn5n1ug59qqzakr9euapzor7yim X-HE-Tag: 1688697512-432507 X-HE-Meta: U2FsdGVkX18aXevG/SDzwhhIeHyHzxwNCI8J+sQDKQcHj0YIm035QYxahdAV2qGDZXPPa9Pm4lOAZo6ZR4j6J4cNqwQs0LeUK4Cm3rWasHPnK6K7oeTQ3pErCoCv5JIpTrpKEjW9Mxk8tbfDtX488KFoHhHBUly7/BGe0LMhDH6a+9r1Q+qUNPb+KHLl9sYlADKIYmNsy70eeKavazJNRc4+yVII+AJl2BKVqfzPw6tmu3vsxeO3xrhcy04Pd//BTsg2b+GgTMJHZu8I/wVxu+0eQLOCBF3nd4MhNWcUtdBuOI39lnPemZbxUY50W+0EXjnb47mFwsjvcqJ72XIJLlA1KLS4HZYdNHUx4z3ABOhKAyO3D+q3fNyMRuIWSuTcUgKZA0V/nixH5EMQ+cW/4YmQNkXABQxPMuGINKDP9TKGAz12IL4rQiaMFIcPkfCpT18it8mc/VfuwrUUS4Ojk9qocFf02K4Gws8NkARw+pG0eeYwtx7qMFdiE9R1f2ILWE5UATIyuXwINZFZGGzOtpkPY+Vr2Pw8mdEEwU0tZrA/sRb7OrDskEYBo40fomfS0qOtPC2AnHm0vWInQsDoOBAtODv53H/6nvzo4kEAwPc7OKfCi9bEJ5rtkZgRTjQx1kMPFywN1BkE+FImK2tkUQqZy0JfMtg9lHG3Dq+Oau64L4zYSGQsyz1C4Apzy52eenFa7kugEuy6fWXgd72SWRrtaenOnPpgVqdvytLN9tD8AA/sy99cktYblzpRYi1Y+LWdjkx3MfAZVTI3jLZ0l7G3oE5acu02mRC4Q49mTyeJFa9dnf6jdmSmTKmxp3fKFz9Mzvv1CA5bJ2Mn605S7Qz4Uq6NEyV4+BXHKwoRJ5fkGsKrZ9d+T66fjqmREH1uZ/Y/PFSbkHIsKVSxSz7Od4D70y4eNeihrRhMWKWV9UhPUwtUHJmkdg3UC2Pm4UzHsRjGuIUIA0OHwBd5tro BDomnPHw +t+4OG6ChRZtOvKf/fjjDfXuPGElGMfH8cxRXczWY2/7uBoS6cETXJenQvSBovD0ATvE5EvMaOSHsvWaR2B7PBkY4CybQQ8FeMqm3juU0ke58GZkhvGdd/5dhkSQanM0572OTAdR8agXaMBcOl1wXMCzUfVj8PBN3pP8LcHCV/Cya4YXIIgm5jhylpPT19qa3SmLmoo0BRD02H5+LxU8rKRCoMJ4B06h7UaagV2Jf/tJFDDAtL9Y7Piqefg== 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 2023/7/7 10:25, Muchun Song wrote: > > >> On Jul 7, 2023, at 10:06, Miaohe Lin wrote: >> >> On 2023/7/7 9:47, Muchun Song wrote: >>> >>> >>>> On Jul 6, 2023, at 19:28, Miaohe Lin wrote: >>>> >>>> MEM_CGROUP_ID_MAX is only used when CONFIG_MEMCG is configured. Remove >>>> unneeded !CONFIG_MEMCG variant. >>>> >>>> Signed-off-by: Miaohe Lin >>> >>> MEM_CGROUP_ID_MAX is also only used in mem_cgroup_alloc(), maybe you also >>> could move it from memcontrol.h to memcontrol.c. And define it as: >>> >>> #define MEM_CGROUP_ID_MAX ((1U << MEM_CGROUP_ID_SHIFT) - 1) >>> >>> I am not suggesting defining it as USHRT_MAX, because if someone changes >>> MEM_CGROUP_ID_SHIFT in the future, then MEM_CGROUP_ID_MAX will not updated >>> accordingly. >> >> Looks sensible to me. Do you suggest squashing above changes into the current patch >> or a separate patch is preferred? > > I think it's better to squash. Will do if no objection. Thanks.