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 68114C678D4 for ; Thu, 2 Mar 2023 03:10:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA2856B0074; Wed, 1 Mar 2023 22:10:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A52FD6B0075; Wed, 1 Mar 2023 22:10:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91A496B0078; Wed, 1 Mar 2023 22:10:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8282D6B0074 for ; Wed, 1 Mar 2023 22:10:35 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4327880FB3 for ; Thu, 2 Mar 2023 03:10:35 +0000 (UTC) X-FDA: 80522480430.24.C53417C Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf27.hostedemail.com (Postfix) with ESMTP id 758B640009 for ; Thu, 2 Mar 2023 03:10:33 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dBcoaM5W; spf=pass (imf27.hostedemail.com: domain of rientjes@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=rientjes@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=1677726633; 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=9C4CCouX2nhWcR3dTIi8dwad3tgYjCWfB/ierikag10=; b=jZef043JDZ1QwzByT1MkmxVvSfLw8q2hCRpPKZJWmN8gopEAwn1XIAdkqnqT+TMHKJSRm1 CKuobG4YjjQMh5APEmuThSikRyt60YIPm/P1nldCS6a3j6Yg7+NDQCQ4YEJ5rYN9gynLon nOC5wyyF39Y/+ijscr9wcbaujOgtfKQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=dBcoaM5W; spf=pass (imf27.hostedemail.com: domain of rientjes@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677726633; a=rsa-sha256; cv=none; b=vfhP6gOeZtjDtyo5HIllRo8ajoclqT0JqpPbLBE2DxUYII8AU8KwJccOZKpkjaT3KmXUK7 VuV7+xbqmDbcl36L9kMQaMZaHtXbvxO1Vsf+3vFt3peDnecy0H5lFAuqrtSYrGbzCRqt55 xOZG6pjisSLdB8Rxquvpt+kWeLKHaFg= Received: by mail-pl1-f173.google.com with SMTP id p6so15334549plf.0 for ; Wed, 01 Mar 2023 19:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=9C4CCouX2nhWcR3dTIi8dwad3tgYjCWfB/ierikag10=; b=dBcoaM5WbJybSOjELRfytipKGhGjw8pnRNWbEZ2inHpYf1VphFL5zewAFo0qVaVYGj ha3nOWrX65LzD0gAmxYggNtXMOwc2TNQOJhNZdnzG7Nn2iDb9H0C+MaJGKjEAgNN+oJ1 v/Dv68AFNvCm70bZF/6MpQBOCD3LUZJ17hZzY8JLsm3Xf57WO7r9oCHpDi2j5mft3c9i /cBfeh42peYXdNhl+3OmKB2uisAwvWM42Mgfqkk/dJf0uTN9/RyRCoo1B1mOf/Pqnl6Y i74JE86IWB8mWSOCqoQdyFptUpG6M+OqT6Kgs6hpiIuq3uYi6N0HVZv9hQ01Mb0jqQo8 /UhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9C4CCouX2nhWcR3dTIi8dwad3tgYjCWfB/ierikag10=; b=dw9DD3/6HtXJDDdltyi/Q+GdOHoLfw5b6jxCNaddRTn0thh6qnjkNU/QRbLpIg6rxd JysDcwCP1Hjv/ppNFpp9pDHKjGbzHdHk4mrU99/378mQHcQOnew0farQ8YMFwvY57iah uutQdAANa50AwYCnJWq9EsHaDCWQAUcqxH3KUdNDPOeDfk9nlBjuThJqZspWqm7OVVSM JyAGkmqiGJ7/oGXEFWbWSZtifZ/hCSbYdnp28oHP25H88+GBYEd6t10HXScguIOU1Nqc rXdg4d/mS/KMl/sJ4W01W/82aEzoaF2rB/b/rEznML/OZE5CHSCanvCHWQ/2q5Eo882A oIrA== X-Gm-Message-State: AO0yUKWiUu5vKr2MQQVLxFLdyQf9c71wPUuXmCpzLh7vdAi3LZrhDz7s 8JY1FtOg+gDfEBaAQGYiieZXhQ== X-Google-Smtp-Source: AK7set8loXb9HnwAzTeaoWVW3yJ6nOcZ5+CLq81aB50D5Fiq/bY6xBeeGWdS0/gubkAac8VOWmk2+w== X-Received: by 2002:a17:902:e5d0:b0:19a:c659:e1cc with SMTP id u16-20020a170902e5d000b0019ac659e1ccmr84481plf.2.1677726631928; Wed, 01 Mar 2023 19:10:31 -0800 (PST) Received: from [2620:15c:29:203:5530:853:8d92:ba58] ([2620:15c:29:203:5530:853:8d92:ba58]) by smtp.gmail.com with ESMTPSA id e1-20020a17090ada0100b002353082958csm492670pjv.10.2023.03.01.19.10.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Mar 2023 19:10:31 -0800 (PST) Date: Wed, 1 Mar 2023 19:10:30 -0800 (PST) From: David Rientjes To: Frank van der Linden cc: linux-mm@kvack.org, Wei Xu , Johannes Weiner , Huang Ying , Dave Hansen Subject: Re: [LSF/MM/BPF TOPIC] userspace control of memory management In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: pxhyr6r6r5uhjdbz4r5fgqhpo8j5kim5 X-Rspam-User: X-Rspamd-Queue-Id: 758B640009 X-Rspamd-Server: rspam06 X-HE-Tag: 1677726633-859563 X-HE-Meta: U2FsdGVkX1/7h2AsXsB1shMqWUMTATFAzrvutxSsGG4trPXGeFLUkKcrWdMTk54vUFPbF/3gNhvttOg+UWgtRHMEBhSZoVU7O+5CLtAkNYfnErOerIqd7m1H4o/Qxj6Z0KldSONMaqD2SgXrXQKwzHMd5LtmC9FmqpNNJqmv8Joa5D/26BaHuKBaSlvLAell/eccJq4Mtb3sV/iTl38QTG4etwuVzJx81Sxki6JBMH4II2okeiC2f2/Ut3cCsCXGHljPUx7Smk+JpKZvtRCdrFbW0BU56wPQ87yHgHUC9tlZAFnoFeIDXiyfYJKYZ3B/OnHp84YrwQCmoKoqw3raqVmZ80vBk1sTSB1O9CN6UdDI1dufH6+wL8fXLcgvu0IzD+tvLwQPgYq3kIkn5AeICTzo7/PEl5u9Y2YY12+crq1U9ZufQnVvKMNMyjduH6pcsrsqkpSM+TUlGI1tZ0J+bhG8pGdnIfJk1LnLBPlCt3KCk7q/PzgIyAITvZArIEdAXkB2xYq5iB/bhfYWAK9uWjac9+PkHt9dQ8FczpVCD8lp2Evd6IDcgEtc1Nhlq1BXH5y7sUAZQIn0Got1QDvP9oGZ0N/kmrOgfvUccZuBgcFsZra7IM+mTuCC7gp7DsvsbjVfkSXQm/AX3qoAe/WA/wIow/M3XWuIxZ3bDY7RgrWaVX95eVB58/CwbYGXlkt0PyV2ZCU8EsVj8TO1T64gibNhilIf9ABC777R/2IcLnhd37/7mJ2z5jcKnYq+G96JED6GPQBChEiluLErtO1H2NQ7+1J1mH3q942dX6aC3KJOakvvbbPD6Prjk6jYddZNZktq8TxFpqNUwd5gWytjyXBCtOYzjANlgr8d/sdJ0XCHVsoH8ZR/f/ILWxm81j3jwXxFZra8ZpgQgSebXwJgo+6MYzFgvO5smtgP1Ckm/gucLXOyzJY4Y4v1X6DamC7v9w8/tI3vcHgPONEuvAX yL5CV3Wh mg2aca1mltGhOxkCKRydSS7Tmr+12H8dX5R5KJudT3jANM3yIim96kGiOjcMwmi7ledwYgCZ2cYRHbx0m6f2SdPk+attza+GYHvggo/o/cNFuAsT0qGfGdj33FEA9hTuNPECJtZIoi5/EzcQ84VMZNxJyRLZIKUdPp3qvT9zhcWQKfiQpwgv3r+fi8kbv6oKzUUHUGY1wVExak93KGOulAV+PwyzyXVSgyX8wODChJqbdJvWq+lEtcZRBXlOHr9PmO8e4DFRUKppxVFQMKiLQkYX+4349wahcyOEFMMaG34UiYVJCUGxyhFHq0JYxJFl8D1Pu X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 28 Feb 2023, Frank van der Linden wrote: > I propose this discussion topic for LSF/MM/BPF. > > In a world where memory topologies are becoming more complicated, is > it still possible to have an approach where the kernel deals with > memory management to everyone's satisfaction? > > The answer seemingly has been "not quite", since madvise and mempolicy > exist. With things like cxl.mem coming into existence, a heterogeneous > memory setup will become more common. > > The number of madvise options keeps growing. There is now a > process_madvise, and there are proposed extensions for the mempolicy > systemcalls, allowing one process to control the policy of another, as > well. There are exported cgroup interfaces to control reclaim, and > discussions have taken place on explicit control reclaim-as-demotion > to other nodes. > > Is this the right approach? If so, would it be a good idea to > optionally provide BPF hooks to control certain behavior, and let > userspace direct things even more? Is that even possible, > performance-wise? Would it make sense to be able to influence the > MGLRU generation process in a more direct way if needed? > > I think a discussion about these points would be interesting. Or, I > should say, further discussion. > > What do you think? > I think this is definitely a topic worth discussing and would like to participate in it. Cc'ing others that I think would likewise be interested. I think the APIs that you mention that already provide placement preferences to varying degrees of strictness, like mempolicies and madvise, won't be going away but what can be *supplemented* by other mechanisms (perhaps with BPF) is an interesting topic especially for users who need finer-grained control for optimal behavior. It's a topic that is deserving of broad discussion.