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 01889C47DD3 for ; Mon, 22 Jan 2024 02:59:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85F196B006E; Sun, 21 Jan 2024 21:59:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E8546B0071; Sun, 21 Jan 2024 21:59:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 662B06B0072; Sun, 21 Jan 2024 21:59:53 -0500 (EST) 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 4D36D6B006E for ; Sun, 21 Jan 2024 21:59:53 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E62AB12066F for ; Mon, 22 Jan 2024 02:59:52 +0000 (UTC) X-FDA: 81705442224.24.ADF1ABF Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by imf06.hostedemail.com (Postfix) with ESMTP id 1DE3F180010 for ; Mon, 22 Jan 2024 02:59:50 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=Cg3eVAbi; dmarc=none; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705892391; 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=6loqEtr8W4/MnoN9hv9zyuRQ/zMGZggVt2HpZC6HiwE=; b=eg2ogHYLYw3MX+Bk2ZjeqsZwEkRkdazQe3+EXnqE5T0OgSt17lqdBoOA9JmPlCD2sNmiQc 3hqr5Su6ZjfB6LJpwkpupzudf+LFRZNPzs52n//Ja1qymP8LGgLyvwHa6sFtsaDHSCiQ2m 3HbQzBhnNOg6ZN3OV5FlDBqYKqEPU18= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=Cg3eVAbi; dmarc=none; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.176 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705892391; a=rsa-sha256; cv=none; b=oJqdtOFePipVu/gfoJZAvjf0SKPa4tzaFVYtWp+frBtVfhJmE/p7lRNLJDc21RLRBobMJh A6DLfwv+QinXTTyCG+VVqkushd2Oaj1WoVyv0p094NBUd/IM4rHgK0XeOItNlNSyNj2Otp qgzkOROgj5w0Qq7zX82OuxBdzVNI+D8= Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-78104f6f692so202660985a.1 for ; Sun, 21 Jan 2024 18:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1705892390; x=1706497190; 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=6loqEtr8W4/MnoN9hv9zyuRQ/zMGZggVt2HpZC6HiwE=; b=Cg3eVAbiSHXF1Gw01pIIpWGPmbaTX2Susdg55w6GHKDQsYP8f4V6yyty78jsrwF1Se DpLaB9Wd1fnxf2fopBf6HfCk6Dalm293DXIoIEwVJGCyNqQCkFeJpI5G28IHchqfhcvv R6+0d67+a8TsHToul2K5t3eru12bkdkqtujSc1FStgHx+85XdeVeK36GruPUpxSj7iSC GP+QV9ZjTCR40iWkWE8Zl5w8rXQjKFySpHTs4i+GgOYCu2AgxTvXtYklWLRDsGHKA1eq gBOSXFbWnjpEGxvwyzh2FvrXV45aBEfsXBfBOjz+WUJ2tk1G12XD3yDSM7sJVNsLZj3t P/rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705892390; x=1706497190; 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=6loqEtr8W4/MnoN9hv9zyuRQ/zMGZggVt2HpZC6HiwE=; b=GlJ1e93zPkX9E7TNAwmQ9UKPVzFAR4Bygk+yrWCh8Pg3TAQS6l9RnUSdzcPAcu0dYB ezBpuuaMjG0EfHL4rCBGsYbcHylicq4fCrexu95XWiEVOZf8orq1/NQHzqloMg99jhdo 3uTW38sj3f0c/sGxQuO2mijCT16Ibt47vlr8p6OZKS+87tOFUMc4wZlHkdwpbhI3SSL6 iS6kH2558lpZVnMsECgOhEEo5O1n1I39NKdpmqRDFz5xD9KhHxdo3Vnng+O/2+p02cj+ Zjsiuqfxc/vWoD9+mf7qPt7NNgMrsVJIXGzvKbNyUSkcHF+5Bo/YyA6Y1SWOvAqdlrn/ /b4Q== X-Gm-Message-State: AOJu0YwESH5wUaNJZZy+w1Chx55YtK3qWGZUOPmV5lguM5mB5GrlgRGE vos2yXBILphfeEmTDMyAAUnA3Ce/+xoXi+ADP8kAEkRFsvEkM0Uijn8LADRBTV/Owj62hPpnq5Z y4hFBVHnSYyN94CxIZlQxnxo02lSt61oceukNxurj0qReGGVz X-Google-Smtp-Source: AGHT+IG+gZyrTFmxZcL/YVdEWM1zZYi9bYnrK6V7OnM6bduS/ZZQ1bpPfQMbiOpqPxopthUR3Y+1vPXte763Qg5XT3M= X-Received: by 2002:a05:620a:1035:b0:783:6e7a:c815 with SMTP id a21-20020a05620a103500b007836e7ac815mr6065985qkk.32.1705882725284; Sun, 21 Jan 2024 16:18:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pasha Tatashin Date: Sun, 21 Jan 2024 19:18:09 -0500 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] State Of The Page To: Matthew Wilcox Cc: David Rientjes , Pasha Tatashin , Sourav Panda , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1DE3F180010 X-Stat-Signature: fjntextpsxt3f3cy6fas19tndk8eocpc X-HE-Tag: 1705892390-696569 X-HE-Meta: U2FsdGVkX18lX50UvUjhegqeD8L6LJSqk180GtJ8xcE2vQUBnIGr+rFy0HT2BsUjf6hzkRtEoQCUWiGDZN/EYb3Swu8tMfws6vgnN7HrzrAquQ8CMqlh3gEz0nxJcglg12ncuOCARwShJcx9eh9+GF0P3UlUBJ3iEpyCGxFaeXHSnEUdEI38k8c9wyl0ie1o9RUFIjVt4r6iZ7Nwu1+0SaLYs8LXUcRmUHispkneihMDCC2xR/fx22uhPZFit4sSlvGZctsXHP+meNtgTYEO1vXp+7pmbs+uMgvVPLURKoaytGr95LFdnHVGHaU8ONNltUzL4Aylzr8b/FpF3qn+tDhE89Obtu3bkeY8cnxRUoexEDh0yi8wDvctCpatxv9yoFnyonM/0QRpoggSR6SNKbmj2c59nnypnNo52GJTAp517Ei4fOOClQQbBU8rMDqkEXJxmi3owUMhu2W3DDAH47J387Sxkc1lbCx3E1mupHxySIRdVjjli8pKLdRwoJWOjInL8WKN/+djxql5AkrgttCe1AaS+p21w/CobeZvM5dhZeL+0lWi1lb8wgHkyAJq+b+a91W+v7JGA6aQieopIIc8EK4wWoiDHyeVZRa0y5odQYyWNctx7u2WoSSb49QC0SZSgaI+T92IHE0Y5diKRdJi64G+h+/5Ow5WfOqk3YJ3+YVC184QUu4PY4yBVcn9AOyQOn2X385OEST/Aa61t30oik5m8UZhZ23VtjU+bcIEizCFT9bDOkRC0Pi12NzS2lR0qifn53ba+srOKcXgwTXDAObWhMp1iQnxM+wWBmo1vLPng29YJNC9o5cp4DyxeGwAPdlVUfZzL4ipPzlPnnVLNl1F/4scoMegr6QrwGL3jIEzMDI+ewLYwPrC35mTkv5ovRa4PMsoW7bOs0DBlJtW4bBtGalLPIvuHMXMM/+DydHp74oObKhps9aOuP1XCjL27M4oAMOVYZlHdxQ sSyF07JB +FiEbzkRY1CW0YC/lrpaAznw0lmiks8d19c+3O3mPIkG1/J3C+6/5Q3c5LOyWKeAfD/eYjB4GomtoFnBsGgYMHNcZBDdW1Og35at6b/jeIqXagcSx+gaYvuxI9RRb2/uVfrYahf38Ab/FtDr/Z/6THCcxlyt9C4X8fphqRpRaG1Bv7H3w9Rmcg4RgweGNHAXJWY7pfTezzmBzbf1eMnqb1Tl1f4C5b6dgAfCkZs4yIHn3G9MwMaViotW3J+3AZTzcT/VnBfnmyQ2cn0g= 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 Sun, Jan 21, 2024 at 6:54=E2=80=AFPM Matthew Wilcox wrote: > > On Sun, Jan 21, 2024 at 06:31:48PM -0500, Pasha Tatashin wrote: > > On Sun, Jan 21, 2024 at 6:14=E2=80=AFPM Matthew Wilcox wrote: > > > I can add a proposal for a topic on both the PCP and Buddy allocators > > > (I have a series of Thoughts on how the PCP allocator works in a memd= esc > > > world that I haven't written down & sent out yet). > > > > Interesting, given that pcp are mostly allocated by kmalloc and use > > vmalloc for large allocations, how memdesc can be different for them > > compared to regular kmalloc allocations given that they are sub-page? > > Oh! I don't mean the mm/percpu.c allocator. I mean the pcp allocator > in mm/page_alloc.c. Nevermind, this makes perfect sense now :-) > I don't have any Thoughts on mm/percpu.c at this time. I'm vaguely > aware that it exists ;-) > > > > Thee's so much work to be done! And it's mostly parallelisable and a= lmost > > > trivial. It's just largely on the filesystem-page cache interaction,= so > > > it's not terribly interesting. See, for example, the ext2, ext4, gfs= 2, > > > nilfs2, ufs and ubifs patchsets I've done over the past few releases. > > > I have about half of an ntfs3 patchset ready to send. > > > > > There's a bunch of work to be done in DRM to switch from pages to fol= ios > > > due to their use of shmem. You can also grep for 'page->mapping' (be= cause > > > fortunately we aren't too imaginative when it comes to naming variabl= es) > > > and find 270 places that need to be changed. Some are comments, but > > > those still need to be updated! > > > > > > Anything using lock_page(), get_page(), set_page_dirty(), using > > > &folio->page, any of the functions in mm/folio-compat.c needs auditin= g. > > > We can make the first three of those work, but they're good indicator= s > > > that the code needs to be looked at. > > > > > > There is some interesting work to be done, and one of the things I'm > > > thinking hard about right now is how we're doing folio conversions > > > that make sense with today's code, and stop making sense when we get > > > to memdescs. That doesn't apply to anything interacting with the pag= e > > > cache (because those are folios now and in the future), but it does a= pply > > > to one spot in ext4 where it allocates memory from slab and attaches = a > > > buffer_head to it ... > > > > There are many more drivers that would need the conversion. For > > example, IOMMU page tables can occupy gigabytes of space, have > > different implementations for AMD, X86, and several ARMs. Conversion > > to memdesc and unifying the IO page table management implementation > > for these platforms would be beneficial. > > Understood; there's a lot of code that can benefit from larger > allocations. I was listing the impediments to shrinking struct page > rather than the places which would most benefit from switching to larger > allocations. They're complementary to a large extent; you can switch > to compound allocations today and get the benefit later. And unifying > implementations is always a worthy project.