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 C45DBC25B7C for ; Thu, 23 May 2024 15:41:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C24B6B0096; Thu, 23 May 2024 11:41:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 172E26B0099; Thu, 23 May 2024 11:41:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 060956B009A; Thu, 23 May 2024 11:41:34 -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 DD1156B0096 for ; Thu, 23 May 2024 11:41:34 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5E86B140679 for ; Thu, 23 May 2024 15:41:34 +0000 (UTC) X-FDA: 82150075308.21.64D0988 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) by imf05.hostedemail.com (Postfix) with ESMTP id EBF4C100020 for ; Thu, 23 May 2024 15:41:31 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=N7u94VDX; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.171 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716478892; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=i8YxSbs/hHqW6i+09UfLC6ZXnGQWJ1Wz3mWvda8gqJA=; b=2rLOlRlwYjGrIMhXd/jFqVZBD7I5S5YAFOxuODf58D4IiZPr/J+wub6RjQHJXtYoIZw5ev DTKWA91HOaJdT1fx3r65lJwF2DKCmX/TNCxKfrHodnG+V/UXokwVU8KdLZQqvk9m1DPigz kE4AmWUBm0zZF85u8gE0XCe0h3Qs2CQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=N7u94VDX; spf=pass (imf05.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.171 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716478892; a=rsa-sha256; cv=none; b=SUOr+paBtpfIDdGZdGo2DrN/MZcFDOudreiz25fxm0ZnSgbeewn0QdTLWeH/3DpY+I7yBH 74osbiac+u5vI9KZYmiMyJl9OAGTTvB/gG9caYYairHxk5YQQ6PDe8HxWsYiYglzFZcyQY GNLD27dvcbv/imJ9QxAbxGhHmUYMQnQ= X-Envelope-To: willy@infradead.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1716478890; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i8YxSbs/hHqW6i+09UfLC6ZXnGQWJ1Wz3mWvda8gqJA=; b=N7u94VDXt68cQNxxQaj2EpeuKCUKC+rAIuIolRC9Yxz6GfmdnR8oC9t4YB8D1KD4qmfyfx pSLAjViiop8zBTGVV0dNNRvfpGvkodwl31UsFpOjlSy4Os4inCqet8DWIaQZdQqmI2f5su XUceER8lHTKERCR8CMq1HophrpI3mnY= X-Envelope-To: wangkefeng.wang@huawei.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: mhocko@kernel.org X-Envelope-To: roman.gushchin@linux.dev X-Envelope-To: muchun.song@linux.dev X-Envelope-To: linux-mm@kvack.org X-Envelope-To: cgroups@vger.kernel.org X-Envelope-To: urezki@gmail.com X-Envelope-To: hch@infradead.org X-Envelope-To: lstoakes@gmail.com Date: Thu, 23 May 2024 08:41:25 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Matthew Wilcox Cc: Kefeng Wang , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes Subject: Re: [PATCH] mm: memcontrol: remove page_memcg() Message-ID: References: <20240521131556.142176-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EBF4C100020 X-Stat-Signature: motuiw1daynaetphxwjy5qatjxh53eg8 X-Rspam-User: X-HE-Tag: 1716478891-142132 X-HE-Meta: U2FsdGVkX18B4ZIlvXhqJ9+Y0ikMZM3IJyH3/c5Z7M4NmzJFidT39t9RXbQ0v/zW5UBXV6y0vg5Ml/05OZTn87HlEf1bo7hYqVK3heNEVpMW9mZwvmbyJGjuUZf4Y8jVscZRAyNw9jWfRUbPrQMVkMiFEibHpLNErSk465S1BuSkl6H8KMe3MI3P7ByoNG6z3iP9FwG1pI+uj9IQ/+AgDcMQWYjrSofyteJ9kvkBo2bRJJJLQ6bIcXwVpv3oqmJMB19yU1gt1CS1wEPOw9TYOgqy6cQZouWZnqFhNkXl6Pgjm2CZCj7SBwlsFyl7G7aq/blpZ/Iu+djClRKwFavPe0PTZg1LKmVd4k3U7v7KBdylIhcr7vzUnzpCs64VD/UsTCezBE2kaxrWTg5gFqKyBqQuaLpwPDjo9q0KU+v5G4r4v8ZwFOxvMGh3ZOmjsjf95TCEJo1nOJ+Vk5Zy0+sAXMlwEmEsQDEldIsXiOlwRYmtSS6fAQD1tQi5yjAk7/jpZrRmcVHXoiRlyQ2C8czgKUBtHd2kUcnqmZPXnsZSGzL10hxQhkPOvovelbbT6EYqtJRHYOu3u9Fjxih2rEBrS8AOD8qYCFUjWDpQ99qTquqsBd6Ferin5TaXCTlnaH8XX3rXI5kydXrcELK4VeD5OuK6n0qisLRMXdA0646dp1sHiRCXykEos3khNXYKe5RS2hvRVHIe5q/pcb9mgpKX/AsTSUk4GDo0SIzeMawEcSFm6v+KVn22wcc26ajhoS+c3nIBK661ehKMeuEb8zAXbr7c5B5UMfv9/wdeCFjHEbEjVYpfk8XutJ+aj3EJgf2YNT9Pz9R226oqHQ94OgtMlDdlBemhca4r 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, May 23, 2024 at 02:31:05PM +0100, Matthew Wilcox wrote: > On Tue, May 21, 2024 at 12:29:39PM -0700, Shakeel Butt wrote: > > On Tue, May 21, 2024 at 03:44:21PM +0100, Matthew Wilcox wrote: > > > The memcg should not be attached to the individual pages that make up a > > > vmalloc allocation. Rather, it should be managed by the vmalloc > > > allocation itself. I don't have the knowledge to poke around inside > > > vmalloc right now, but maybe somebody else could take that on. > > > > Are you concerned about accessing just memcg or any field of the > > sub-page? There are drivers accessing fields of pages allocated through > > vmalloc. Some details at 3b8000ae185c ("mm/vmalloc: huge vmalloc backing > > pages should be split rather than compound"). > > Thanks for the pointer, and fb_deferred_io_fault() is already on my > hitlist for abusing struct page. > > My primary concern is that we should track the entire allocation as a > single object rather than tracking each page individually. That means > assigning the vmalloc allocation to a memcg rather than assigning each > page to a memcg. It's a lot less overhead to increment the counter once > per allocation rather than once per page in the allocation! > > But secondarily, yes, pages allocated by vmalloc probably don't need > any per-page state, other than tracking the vmalloc allocation they're > assigned to. We'll see how that theory turns out. I think the tricky part would be vmalloc having pages spanning multiple nodes which is not an issue for MEMCG_VMALLOC stat but the vmap based kernel stack (CONFIG_VMAP_STACK) metric NR_KERNEL_STACK_KB cares about that information.