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 3882CCCF9E8 for ; Wed, 25 Sep 2024 17:39:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDA026B00C1; Wed, 25 Sep 2024 13:39:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B89C26B00C2; Wed, 25 Sep 2024 13:39:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A50E46B00C3; Wed, 25 Sep 2024 13:39:31 -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 83A7A6B00C1 for ; Wed, 25 Sep 2024 13:39:31 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0598880F8A for ; Wed, 25 Sep 2024 17:39:30 +0000 (UTC) X-FDA: 82603972542.10.292FD90 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 1959240018 for ; Wed, 25 Sep 2024 17:39:27 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=N8afPNaX; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727285871; a=rsa-sha256; cv=none; b=4L0sr7H37fJY5ciHsnsAY3GqvLzknIaXB5bhviv+/sMsSvEu1yg4LA2DLZOAVuMeZBYKKN lS+/jqTaRL1XKY6CPYr6qM30N6zAoZN5UoDTWD1DGp+5oHoCCX9OFr50XNkMHxHAPNbi5d SJndrj0jz/rWyDGl53zuKe16eJHJfa8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=N8afPNaX; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727285871; 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: references:dkim-signature; bh=ImQW5AV6fQCM/oolg3TTzQLsJSGPTECRk3OLZ6QSceI=; b=aRGH0G+7TQU6xtayamNJmPvMEyzy9gedXQ0NI6+r4TR21G347je/KIEWk8rbgls8BCRrhq uF6hsBRUBwiJ6avfu4wxApz0W0HHkYr+nBnR9f7d4MtqmENseKcwXvn+D+aAOTwnzgoCcW mu7oO69vvU0Hh4J7gDmt2lVMCGBWrZw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=ImQW5AV6fQCM/oolg3TTzQLsJSGPTECRk3OLZ6QSceI=; b=N8afPNaX+0u17g5DWY0eXEYMui adCsr3m9hy4K+dOzz/iNB8zNWO7Ajde8zxIMNVvqkj5pInqpbaaBiRpx3QlWs0owExMhdCr93Xo7C cK7DRTADahMgnm2ByqjmUwpo+D1MpXbxBhhc4ndvmKYcYsWQ/solnQ69XxnQKBRJIqMp9vBwaEbn+ A0KQwbnrSDptgRoxVl/XlTLH/hqHSfrcDYVfWWmC73rkobLzD3JglEM6d/wYOZq6QcEI9urn+X4aI +fwX6pjsrT3W9slRLsYmjlEipNNHZ8nVgKT4iHzJiIDpYL48PyI/JcICWuJmtqUZ4/n8aci5I/Cy3 CYgQGBfQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1stVz2-00000004Va7-3Ubq; Wed, 25 Sep 2024 17:39:24 +0000 Date: Wed, 25 Sep 2024 18:39:24 +0100 From: Matthew Wilcox To: linux-mm@kvack.org Cc: Yu Zhao Subject: Next steps towards shrinking stuct page Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1959240018 X-Stat-Signature: 8sxiuqudzae48m5n7awqbbort674ffzk X-Rspam-User: X-HE-Tag: 1727285967-341895 X-HE-Meta: U2FsdGVkX1+HDLLZkF+oU9YLQ6Iln7Epfug9YLyJ3H/rhhX43aKHNG+xpmjo4IFXd8hXtIqy9ttkATminUiYCNaAYCJv/3LS4MgHEyeZyh8wBbfTtIR2C2ANu0sQ4u2Yd1sDNAwRT1pugFHJyewgPpkAGQh1uLpymA4+o7EFownHWrzgQAQuP0tKPvOow7KSpM7P6r9D3G1fUI/dIqu49baPxx2vLTmnCodX5IOGQtoV/Xw+YUa6nZS2j/mQlueQVPYrOjSIZGIChrr3bQyJSqu3H1QOwEwjlo81eH1D37LteQRNliDGQ6auKwJ1Mpotce7/3S+XteoDqRnYBDCUUZMuC0JXtVzy+t5gz5zkCcddKeh9YTGRbUqDhywJRCzmiNY4BcOk9npXPCkYrkkdgVTrojNW2RpS+bzv0hCd5KqVvxazAI/mO6mzb2uN3LmIAOG40hrF9uXLz3d48TWji9qkGk/y5WoRz2412CSTT0c7iOZWxIBswhbdjBpZ4n7eQCMOPZQco4B07LY4SlB5/3GdKN8xIYI/fFOPM9jA+VLwU9bm/JVZPIA81+N/1yP3yBFXu/DbQpd4M35LDrEJNKTFA9HvtBvJSUP8rEEYPdC+YBd61wJVHcona3Iy5Bj2BBxsFjVLWARxMNhzt6N06v0HZdNMmO7S2jwWl+prGITuiYnOnAB8lmeu7AhRyjvYyCZ1GsLVC6wBLR3wT1GdlGZiMwUmx92X2IoZrullIRlgY9sGvkmd4hU0YWehal3hacIgFH5zCrS5WSTgty9b3a4CZ7haBzfyx3e/WkpuchRbQV1Lc1ah8WG2YlT/xn36NTgGdZ+7lQZ7+I7tn5TEbLviJk5LZgC5KZaTIrpN2gtok7+jwiiMr9KovFWfVQWqrb0jXABXh2mMLuZxHFbuDvgFDC1ckL5riPNEwqf+OsnFgUAzx6CSY5tk0TelG3tAnsUauw2pO+A9lCRa5OB uv3u+W8/ e3pxFnRWSZAgHMDtadMCLrkjZ22//RfNIzEoXMLZqV6YQUolvtPmcBsKMebnzA6GPiRnB/TEt4klcJu4l6GhuwUOE6nlV2lhyDZTOSHp7mJwur6blYm6rBk3F/sbfKjiFNJ4KUd5Laz8IHHwjbMPSgaQmP+0p9B5IYsvLZrjmAV5nQ6s06KCPa/5VqU6CEMKUzlGFK2BxpRVBP8JFVoCUEEJjDOGjcb07Pn5iEU8H9VufH4FvZko2oK+J/PF4/KB8MlQ8rC18FFhUxHBcHvHZK9y0gkJn7vZIP1srn/+D6a33WTRulR+2K5zf5u9CvJTCA6nqEvANaitrJhjzhXZ+AfwwhwIOCLwa03DhM7hD9lZPwEiZyDc8qgBCSA== 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: Yu Zhao asked what useful steps he could take towards shrinking struct page. I outlined them in the THP Cabal meeting today, and here's the "next level" of detail. As mentioned in https://kernelnewbies.org/MatthewWilcox/Memdescs/Path we want to get struct page from 64 to 32 bytes, at least for common configurations. I'm currently working on getting rid of references to page->index and page->mapping. I have some commits that I haven't sent out yet (we're still in the merge window, after all). So here are some things other people could do: 1. KMSAN Someone needs to figure out if KMSAN is really per-page or per-allocation. Do kmsan_shadow and kmsan_origin need to live in struct page, or do they need to live in each memdesc? And do we care about KMSAN overhead for production builds? (does Android turn it on?) 2. Bump allocator This chunk needs to be pulled out of struct page: struct { /* page_pool used by netstack */ /** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count; }; Similarly to struct slab, it needs to become its own struct. DavidH and I talked about it at Plumbers and decided that it needs to be: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _page_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; }; Some collaboration with the networking people would be good here, since they're the primary user today. In particular Ilias Apalodimas has a lot of history with this code. I did some work on this (at the time I called it netmem; the networking people have subsequently used the name netmem for their own purposes) https://lore.kernel.org/linux-mm/20230111042214.907030-1-willy@infradead.org/ 3. Reviewing the zpdesc series https://lore.kernel.org/lkml/20240902072136.578720-1-alexs@kernel.org/ is the latest version 4. Make sure that we're good with memcg_data. I think we are (it's only used in folios and slabs today, I _think_), but it'll be good to be sure. Someone who understands memcg better than I do can probably find some stuff to clean up. There are probably other things that can be done to move us towards a shrunken page, but these are the ones which come to mind. Happy to elaborate on any points.