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 74833C3DA41 for ; Thu, 11 Jul 2024 14:55:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFD3A6B009C; Thu, 11 Jul 2024 10:55:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EADFA6B009D; Thu, 11 Jul 2024 10:55:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D74E86B009E; Thu, 11 Jul 2024 10:55:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B936F6B009C for ; Thu, 11 Jul 2024 10:55:21 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6D1A51A05EB for ; Thu, 11 Jul 2024 14:55:21 +0000 (UTC) X-FDA: 82327770042.20.BEF5E1A Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf29.hostedemail.com (Postfix) with ESMTP id A507412000C for ; Thu, 11 Jul 2024 14:55:18 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FX2IJKz5; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720709703; 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:dkim-signature; bh=+4UBc7cQrKGMEZ5EX9PJdheM7gdFy4rwh8ao143uo3I=; b=TgcKrm/RvwaCBeijKVS+WhOIzizpWqpoMWoMtKxIZSDC+iC5Iza6vKMJDE0EgTkxAQgShu 46sKenAtKvT1BtagnOIfeELQ/CDlI7gXV4FQkUIKUd2mIPrcUnF/X5dtoXxvysAuUvJNa2 9eZ/WtbqytRB1kOola5ZwAc5kfZDHyY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=FX2IJKz5; spf=pass (imf29.hostedemail.com: domain of surenb@google.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720709703; a=rsa-sha256; cv=none; b=OlCDvVg4Laq43+N81+1CYujqfjbMvAHlW8YYN9kELe2JGzLJyQi8PE/kZaiUtBZepE8Ted 1Qws0EfzKEdeuzvRuZhcvrTqX95STwsAQ61nkuNdTMoZgdXf4FV6Z4f4q2+tcs5EL3rAPd 7xZ+aua1iIQdsJa4S7CjgueK8+X6bnQ= Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-e057c4885b3so880761276.3 for ; Thu, 11 Jul 2024 07:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1720709718; x=1721314518; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+4UBc7cQrKGMEZ5EX9PJdheM7gdFy4rwh8ao143uo3I=; b=FX2IJKz5Vki+qaopapRQ9DEr+b22+y7v/0eghA7eznk2sFreGN0xtZTtzTgp4eZEP+ 3fpL59J7QfE6pZnAeoKN47wJ7Q4wm1unybpueM3aNvqF6jEIHQTM+KjeedEo/q/JCs9r 2m0zjKDNSb7nxErl0oCUiOcBjVIlYu0F5NB6GqHnwMfArWo8qZFUKV3us3Nt9rS8WtMW fLTgOQ7XSgURngWF+h3UH+PE66V88gx2aZu4gVz0gHjzrsCIN9KbrkIhuEK6diAYJDU4 XO6xCid5KWNons/fIJddU9lqLz/6V1GEu8HFA7bG/+/9wfailglTGmuxzNz0J1HI2aEV kvLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720709718; x=1721314518; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+4UBc7cQrKGMEZ5EX9PJdheM7gdFy4rwh8ao143uo3I=; b=w0ETfCZ3HNj//sxCZcf58SsPk5ekNDjEkZYfzB9gq8zJ8SafFCTUwA0YeMxAR0b2q0 R21WEneNVxinaloY2ukwHjJevyjV+rNE9TodKIoIJMpkCbMtsp2wPWwipEIG9+bH+DLZ z4Vqylc0PKHjzfZ1qlX92bZMujy4m8ErFyt4S1a8wXxe8BEzGxGC/vOekVveeAPrRWnZ iovU7HFJur/YuSuBdKOvLLxJ9VlAi9iITEz2yJNaDlBXSr07eLN9+lf6AZus5fGpmOtF yiREqaPJnbJ6whLRiXMb7eiYSoiFzNp0WdsncH8EOI0FqcUAJ8pOzTGfBuj0i6XXWsu/ zihw== X-Forwarded-Encrypted: i=1; AJvYcCWYCJl+0iIVh9pd5p4QS/VYWp70QZ3V8xbgpPlcZJEHqtHPaIpQgUIWbLFF4jMXWlR6UppmGMeduHF9h1/2XVoPHhY= X-Gm-Message-State: AOJu0YzYFrxbnJt3ggX59eanaYJFeOiNY9VngP0gJyMLqmNdvDE3I/l5 nHDI2Y0JtjJIqQaqrUlmKisONH0pjIc7MZB3IDAl0iLOHrKPj5b3REyHhe/eIAlJq9bedguKhfX wwWnFWkjbYj3iDjnAgjNQ3yeJp2x8JX3YclRq X-Google-Smtp-Source: AGHT+IHOZ97p6Fxs/TNwZed9HbaLGEz1VBSjOeoNgLDM9j7jU98gIWaZoq4aET1Gv+kkFrFw7jxV99m3/gBZHoGvSUM= X-Received: by 2002:a25:d38e:0:b0:e02:4d55:1e6f with SMTP id 3f1490d57ef6-e041b05c9c5mr9971274276.21.1720709717399; Thu, 11 Jul 2024 07:55:17 -0700 (PDT) MIME-Version: 1.0 References: <20240710054336.190410-1-alexs@kernel.org> <42afbce8-7746-438f-ba3a-c997a2c702e5@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 11 Jul 2024 07:55:04 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] mm/memcg: alignment memcg_data define condition To: Alex Shi Cc: Vlastimil Babka , alexs@kernel.org, Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Randy Dunlap , Yoann Congal , Masahiro Yamada , Petr Mladek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A507412000C X-Stat-Signature: hjqfiinedim1w5kciw676kyhwdeufdos X-HE-Tag: 1720709718-448159 X-HE-Meta: U2FsdGVkX19ies4gx+d7wcsaqgM1c68Koplw9nzxWN6aE0onyzRAvjy6yLp3YkQnODYIS95anI/BD3QGdlwv4pl7kyM4aJVFYoJrOsjUBXDl71grSJnkJz8LvyxehGsob7ADV0PaMrpUHDlfVy108RgB6wafwFX3ASLzc3hX4fEYiIAcZ7iC4upTLl5+cF80ATqo6KKgChtx5MN/V67QFONifCtlzvR04SC/aLEICC4ubKnA6dGy9W87YvQF4/Z9AdBxvsVh4GR3b7I4QSZwWMDT5tWqJlKoz5lHIvWCjDRleUzqOzCsG9aiBsADbmbG484AhGg9Lj5prT7ZpKOUAgYEYhwX1YGbySUFb92Gyp4dXJobAbaPoesm0ABMWNF057pyRFJ7ZCZypK+8q3VVqDHcn4o1hBVEYbiVPlSZqSuQlz4NFHSHuYKpldxfkVKGEojHEuPOGTIVvwaUNlMz1NSIFMHs1YmtnUBLZcqRLvnvY3xLvGDq2/L5+JuL+qjredllWtgcidBONF7WMpYwKYFiofj1q9E9nWAWzBvaiWmXK6U8Ib77yCV3ggkximN3Rz/OSMr9hOAtuZ5po2KeA9r1GElmF7coHZUgKv49uszS+U7k9kOtK55iHXyFAhuB+6I5f8BFT1rKYF7Csql441kk1JuTJRP+C5rRySiY3TUsoQrqlX7GCve1miU8fK0UXQ60RqbMZtqSw3/bQ2ai/qbP32Xw9vfbUaxdvD913Q9ENcGmQaELONTiMHX6Gc/hQOygRj7dL7MUt8rzvHXs6uWmNEDaKwl83cvqrmjDt+5pLu3BYc1oHHc98ZImzKJG3iQ0PJaKhnTmGOEB88r/Vu7SsqtnEMiRnUKQxoFhRHxb9Kl6BpZp2xk80l90dKlMGY7SfRqUCAonDkZPBIV4jLmRn14OVMFmzay5oHMasxKtcPHxFXm/hbDyZ4omQZ3VFwtSkL44H6m3B6NQDmf ntabzzTv Wv+Tjxp8g4PKxq5XZHJXCaOIbWIvCiTdZca2hGCdN8sug3RHfaOtjrxC60SeBY1qVj6gn945WYVF9ODQpyiPyveNQE8iXmnY4f5YZSW/MSC+te118nAZKoKiXr36BgJmTXPDBRNIEJWvvUOiCyjt0IbiQGo/8PiNuxsq3d5LpGoZVihGGBeoVDqQsqQkvAMhqFZN6fXAf2NeTSh7nxZ/x1FiPKfwPICAg/iqPuU1NmafXW5HZsLwLUyjzaJYPjtnPopfXY5Mw7UG4vD0sfOJqnD2nNOKpwJvDVX+W1A0JEAZmHZrcBZEl8gyCrSXAjdNFI1D0ah6McTJSddorCpSAvHlF9+Cts4z0khNBHXh6OSr+A7VvcgHLefh1Uc67gC3s+VEZ92CEUqr9D9SAMSlGrI/Bg0P/Mmqx8rIgY95yA3znam1+osKwMYrD0eRUKoxk+vfeSKyzxgUxC/pTnQw3Z6/Ht7oZgJmrwngG3Bc193w3GuQ+LAbvo9bOsfoXhmsAuLXmLaBySoOLgGE= 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: List-Subscribe: List-Unsubscribe: On Thu, Jul 11, 2024 at 4:51=E2=80=AFAM Alex Shi wrote: > > > > On 7/11/24 4:13 PM, Vlastimil Babka wrote: > > On 7/10/24 7:43 AM, alexs@kernel.org wrote: > >> From: "Alex Shi (Tencent)" > >> > >> commit 21c690a349ba ("mm: introduce slabobj_ext to support slab object > >> extensions") changed the folio/page->memcg_data define condition from > >> MEMCG to SLAB_OBJ_EXT. And selected SLAB_OBJ_EXT for MEMCG, just for > >> SLAB_MATCH(memcg_data, obj_exts), even no other relationship between t= hem. > >> > >> Above action make memcg_data exposed and include SLAB_OBJ_EXT for > >> !MEMCG. That's incorrect in logcial and pay on code size. > >> > >> As Vlastimil Babka suggested, let's add _unused_slab_obj_ext for > >> SLAB_MATCH for slab.obj_exts while !MEMCG. That could resolve the matc= h > >> issue, clean up the feature logical. And decouple the SLAB_OBJ_EXT fro= m > >> MEMCG in next patch. > >> > >> Signed-off-by: Alex Shi (Tencent) > >> Cc: Randy Dunlap > >> Cc: Yoann Congal > >> Cc: Masahiro Yamada > >> Cc: Petr Mladek > >> Cc: Suren Baghdasaryan > >> Cc: Vlastimil Babka > >> --- > >> v1->v3: take Vlastimil's suggestion and move SLAB_OBJ_EXT/MEMCG decoup= le > >> to 2nd patch. > >> --- > >> include/linux/mm_types.h | 8 ++++++-- > >> mm/slab.h | 4 ++++ > >> 2 files changed, 10 insertions(+), 2 deletions(-) > >> > >> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > >> index ef09c4eef6d3..4ac3abc673d3 100644 > >> --- a/include/linux/mm_types.h > >> +++ b/include/linux/mm_types.h > >> @@ -180,8 +180,10 @@ struct page { > >> /* Usage count. *DO NOT USE DIRECTLY*. See page_ref.h */ > >> atomic_t _refcount; > >> > >> -#ifdef CONFIG_SLAB_OBJ_EXT > >> +#ifdef CONFIG_MEMCG > >> unsigned long memcg_data; > >> +#elif defined(CONFIG_SLAB_OBJ_EXT) > >> + unsigned long _unused_slab_obj_ext; > >> #endif > >> > >> /* > >> @@ -343,8 +345,10 @@ struct folio { > >> }; > >> atomic_t _mapcount; > >> atomic_t _refcount; > >> -#ifdef CONFIG_SLAB_OBJ_EXT > >> +#ifdef CONFIG_MEMCG > >> unsigned long memcg_data; > >> +#elif defined(CONFIG_SLAB_OBJ_EXT) > >> + unsigned long _unused_slab_obj_ext; > >> #endif > >> #if defined(WANT_PAGE_VIRTUAL) > >> void *virtual; > >> diff --git a/mm/slab.h b/mm/slab.h > >> index 3586e6183224..8ffdd4f315f8 100644 > >> --- a/mm/slab.h > >> +++ b/mm/slab.h > >> @@ -98,7 +98,11 @@ SLAB_MATCH(flags, __page_flags); > >> SLAB_MATCH(compound_head, slab_cache); /* Ensure bit 0 is clear = */ > >> SLAB_MATCH(_refcount, __page_refcount); > >> #ifdef CONFIG_SLAB_OBJ_EXT > >> +#ifdef CONFIG_MEMCG > >> SLAB_MATCH(memcg_data, obj_exts); > >> +#else > >> +SLAB_MATCH(_unused_slab_obj_ext, obj_exts); > >> +#endif > >> #endif > > > > Why not also #ifdef / #elif like above, instead of this nesting? > > Uh, it works too if MEMCG/SLAB_OBJ_EXT decoupled. > but right, it could be written with #ifdef/#elif. Yes, please keep the same condition, otherwise it gets confusing. > > Thanks > Alex > > > >> #undef SLAB_MATCH > >> static_assert(sizeof(struct slab) <=3D sizeof(struct page)); > >