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 8ED79C3DA5D for ; Mon, 22 Jul 2024 07:32:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20DA16B0089; Mon, 22 Jul 2024 03:32:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BD756B008A; Mon, 22 Jul 2024 03:32:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0846E6B008C; Mon, 22 Jul 2024 03:32:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DF9726B0089 for ; Mon, 22 Jul 2024 03:32:07 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 61F1C1C215B for ; Mon, 22 Jul 2024 07:32:07 +0000 (UTC) X-FDA: 82366569894.03.17B9311 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf26.hostedemail.com (Postfix) with ESMTP id 6EE8814000E for ; Mon, 22 Jul 2024 07:32:05 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ObRbVXiQ; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721633465; 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=i269Kc+JDPQ/TyuE2xQA6LopPQVgugZnDypSMxWIn04=; b=ctDtl3XjpYENHF542+0ygl/YX36dofp4Xek/9oMQCo5q+8mBtKsXkfIg2O7yoCuzMHbakq YH0a0I6+vpZIdA2WvaarZJA6dInjwWgr16DZJzmudtSWifu9aavJJ4RG7srBC5MVc1nxUM 79Q8qfNpUKx2ar3vsEkEMBoxswRUXjU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ObRbVXiQ; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721633465; a=rsa-sha256; cv=none; b=ooOLC+X4Ll3K9OOxM2LzjpNbz3vqvVR0d1OW8DIHukStVTgHcDcguBNOcy3BrP+yAzow0l y9EeCHlMm3Z4HbPe5luf2mDb8wSObHtMVLA0oGzPUvUTCyprmKWzdrhP5KYWs7DwpR4iyB JUrNf80AUO68Y0ubu6PmP+7BzCAJC2c= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5a10835480bso2878481a12.2 for ; Mon, 22 Jul 2024 00:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1721633524; x=1722238324; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=i269Kc+JDPQ/TyuE2xQA6LopPQVgugZnDypSMxWIn04=; b=ObRbVXiQS2JQxrBpNIqnuVJfY6WsamzsEF33oOx5hzq8vBLh0JyBrnUm4Jt6hI6YNE +31w1tUGLMqpFF0h/3e/7UDSYFrzVJVZLAurmP1jRbNoI9JmWqnWH1iQfYYXCzLNxnjV mHjkr7RsqGRQbo0NTy2EHm0wQBru8GgpCFhy01EczRcpfQYUQXOIrN35DAGMLFJYOUlJ NG6nvzYjwNtoKCLaqVt0FxuAdbf+7kDckQpuKP13RuxUP4/O2lu5yVxqyOmr55GMfabo Ty57BGX57SSGDOlF7naUe07g5HCJRY7o2YqpcCSJ4WiZO5hs73qVB1OlF9AHM0j8KRaq vEyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721633524; x=1722238324; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=i269Kc+JDPQ/TyuE2xQA6LopPQVgugZnDypSMxWIn04=; b=vb10ACj66QmKT/5Z8PHH5fReIkpt4ssPmPT0ECz8eDf9SBNrRYDqiohfycaJ/TPHqM d3J5D9qGLHKQKOL3fzhrfLdjWN4DCtf+KQohGXU1P+7o4H443t7KNfbKp4lFgDETDJOP 3SdGhNDqIhM80EHdUzcqEBGd5KFryllah8bvjAaYwjQ3GwBdgN+TF+fka5WLz9tvP+pS pkGfEMIR+gl8ljnSRjpDUqePfJB7zoLKZWugHpS542bpRVsj/Ge2Or2LppDXCG/tdYck GzzfnsZjbKD5QZex3gJkQ+OkcH/ejCgNRuComqt1NVspKE7vE2PhX84gzmKGPVJsdVbo qIvw== X-Forwarded-Encrypted: i=1; AJvYcCVfkFjq/SampYm0Rkynv2i8Thx3o4ASV2ZHY0UL08bsAoxR0XDj/qZTZjP3H88xKidO3xgX/DZKtzQmvD6QjObltKw= X-Gm-Message-State: AOJu0Yz1VL9IXcaTjUzhsC32NoCoklT8NUxznq6FwGk/EzMD+TFKPBKP /oyK+EBf84pi8SJbYslYHoqSct6lAlV21rUK9+gj7xp3OJ7pe5EQw4hLzoth9f0= X-Google-Smtp-Source: AGHT+IGfYvZSQdoNDjDfGgqoYMTf2sBhdVIo02uRK/M2b/n1L8OwC9uMVh0ZyAHuCVCP+3HC+bl+Dw== X-Received: by 2002:a17:907:9489:b0:a77:e31e:b5c2 with SMTP id a640c23a62f3a-a7a4c42a78bmr290459766b.62.1721633523779; Mon, 22 Jul 2024 00:32:03 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7a3c9511e0sm383129866b.202.2024.07.22.00.32.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jul 2024 00:32:03 -0700 (PDT) Date: Mon, 22 Jul 2024 09:32:02 +0200 From: Michal Hocko To: Qu Wenruo Cc: Qu Wenruo , linux-btrfs@vger.kernel.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, cgroups@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v7 1/3] memcontrol: define root_mem_cgroup for CONFIG_MEMCG=n cases Message-ID: References: <2050f8a1bc181a9aaf01e0866e230e23216000f4.1721384771.git.wqu@suse.com> <54b7d944-37eb-4c3f-a994-13212aa3ed13@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54b7d944-37eb-4c3f-a994-13212aa3ed13@gmx.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6EE8814000E X-Stat-Signature: n8nu3wy59zz8nn3jgyiion9osrxt8pzg X-Rspam-User: X-HE-Tag: 1721633525-665857 X-HE-Meta: U2FsdGVkX19BUp9JRO4lEt58othvVQ9SuZ6eIASiDcLEbiYKJscNZguTghjyO1uI6XgyE1jXVr2jEuyBy/GxvUdn1ThDmPNDGr+KlQSPagX1aa9WMBJ9CPC7eTS8aX6zRr9SosicWWn7YyqUv+qpL8YUFlyAxWYSReG6UZb9EEP6PZ4jVEZhl5dkfaTbIPZOWXlv+2WToDclMT8bp9EY7+5zV4Ujpc82e4ou9AODmzz9F7IRloOFyYTVq0jAirf9/fw8DXDspOBGRSRQ4vCS0G/RgoPt9Pop26u6vLSmNvwm5tayP38yIff24Y+lMgE5TiN/LWGU0DAN5U/DvSGdYOwmyLrUrryKkV9/66uf9mZ5DyCPZ2g1xP5ETAxacLSddqOgsZQCrREXvtBSjc+K7nLZH7n3aQVqmzj90ls9TrgXLuAIX+5btC7RIbH943OXqTLhtcl10uVt4cePLGaRquw0TcLlQNdlRN0dHOKr1CO0vzj5tb9XBkFyQphbTnChlfgbNEXkRv6Vx4jPd0ZMcdlss8uB5HEXxQA0w0/PWN4u1ovnl8LUXZN23ID3vs7k85hM0oimn3x4gZANVQqtVeCXZ6EO6FpnU6oKHaS/oODkhI6V721kAnkPSaZ0NRnBT+YkDm+gFnHATA04fEgGFo8ttA7eWN3tBlINUpODhNvlN0NqY5JakQGr0HSIQcNH+4inUp6Na6mWDBP1sGQa4x+gJ+CGqgbP2ZgxYL/ctSKBAt4pzoR45RlR4oPxRI4uSypnwv940Bz4h/jq6qONf8gk9gR9X2L/XN1SWW7p5mSxyaIIcdWytuNrO2Df48SVDwFwvNX0jCLoUyxCokkV/ReyMlhGCIDSXmyNP+E9ApoCowtbqiNsvHfBuxuYlUB+XYAvqjA+DiVh/qx770Hw43gbLU1MtmSKXFDIko+dL2u/9aCV39WDdYyUeK28+OJwYSKUUg5OQuopIYWe5Se ni9jlWDF wH/KXpUBc9SOPoWdr85jWv2rno+/hBunDXp3bg8vdG3IeF4wK4y9buli4n3qgrNI1EXIasKdsS87+3LSGWpBHt7pebg1Hy21JX0hOhRRAYmF6iI8IGEmPrXOIOtWtqWWnOGtr+f37rBxconPeY73CX0sVnv7vaMwUTkSrIZpqVMzBjyLGGudf26YDU+B5IvDkxIhsanKnPP5GQJqJVMfhXzrZmlyS0Srq0a6OpcyNgtYLFiMxKingTiE7e/FQQq7szEp8f0pBRg22S/bFYMT9tfgP56triT60Ay5xkPTPOpvU91l1eto23x5IOQ1mz/T7b7IGibGzBC+zrYnztmeqMPGmokKsKuMYS36N 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 Sat 20-07-24 07:28:45, Qu Wenruo wrote: > > > 在 2024/7/19 20:43, Michal Hocko 写道: > > On Fri 19-07-24 19:58:39, Qu Wenruo wrote: > > > There is an incoming btrfs patchset, which will use @root_mem_cgroup as > > > the active cgroup to attach metadata folios to its internal btree > > > inode, so that btrfs can skip the possibly costly charge for the > > > internal inode which is only accessible by btrfs itself. > > > > > > However @root_mem_cgroup is not always defined (not defined for > > > CONFIG_MEMCG=n case), thus all such callers need to do the extra > > > handling for different CONFIG_MEMCG settings. > > > > > > So here we add a special macro definition of root_mem_cgroup, making it > > > to always be NULL. > > > > Isn't just a declaration sufficient? Nothing should really dereference > > the pointer anyway. > > > That can pass the compile, but waste the extra bytes for the pointer in > the data section, even if no one is utilizing that pointer. Are you sure that the mere declaration will be defined in the data section? -- Michal Hocko SUSE Labs