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 0B6ECC77B60 for ; Fri, 28 Apr 2023 15:00:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7693D6B0071; Fri, 28 Apr 2023 11:00:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F53B6B0072; Fri, 28 Apr 2023 11:00:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 593366B0074; Fri, 28 Apr 2023 11:00:21 -0400 (EDT) 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 46DBC6B0071 for ; Fri, 28 Apr 2023 11:00:21 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1371CACF69 for ; Fri, 28 Apr 2023 15:00:21 +0000 (UTC) X-FDA: 80731110642.25.D916D71 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf02.hostedemail.com (Postfix) with ESMTP id 1DDFF8001D for ; Fri, 28 Apr 2023 15:00:18 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=nCPdOp6x; spf=pass (imf02.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682694019; 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=o8EEg/8Nk30pjshsO/2Z1AI9OI2HuVJvr0g3yPLFTMM=; b=TVrLFjiKLxMsITlowQf9llkG5K2Dy0H3xHrOUidwfyd+naI5R7TTAQd1ks3upXIoR4nHi3 zoijSczu3gFaPfpiOzSA6eanQHJ0c1/fZg2DmEPmHQtA6Qk9gBgLRcmYphozErK8pGHRr/ 8/JDl3fYO7mjdFdgppEFcEraZ5g1rik= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=nCPdOp6x; spf=pass (imf02.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682694019; a=rsa-sha256; cv=none; b=c4Tv6qS+/3OoMKnVBsJlv11GOk0pwntu6syWEO0HCkwDPO9PAPHXHISZ3aJQRp30F2S2Qw he+4lZF4VU7403Wau0DeI+Zgn3KjbQZguejfLRFKDcZV15RF3InYO5dhY4WoiXKx0Ad1Jz cM6LDubKHFE4TcDXFKtolJyyKzKpZmc= Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-2fddb442d47so9139268f8f.2 for ; Fri, 28 Apr 2023 08:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682694017; x=1685286017; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=o8EEg/8Nk30pjshsO/2Z1AI9OI2HuVJvr0g3yPLFTMM=; b=nCPdOp6xPD5820MgEx9sE8nh5GFARfQFqLBR/i43CJcXRz0/J9LNs0l7DZ9X0OuVz8 xTlMjPg9mWx99sslAEdbupOCKFd8YQJkQq3/E/2r/nb3b2hMV2fV25Ntu3O5NNjnax70 qpd0GQs0uT8kdUsWXj8j2330tNE8/tSF+zvxinhwEm5X3rGqtsJ7XxArJFxm72v2rTtn 2nxUzSxr4/6UtP4W+3SCkws/6vqoqsYFXIPFesPnsQd4RIWeZykpfo30SFggd/OThyie 5yhJtDjj2g1daxkJLVtTesr8NclOhN8Lktuu1s7J2TGT7E8icEU2jo4ePrUEL6zjEIST eE9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682694017; x=1685286017; h=in-reply-to: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=o8EEg/8Nk30pjshsO/2Z1AI9OI2HuVJvr0g3yPLFTMM=; b=VpFVrRA6yN23BDC03IAkRXNbQdmv2s8KAo9GkKclfwhxoj7Ntfw8vlm0Ja65Q5JEE3 OAXBWXOpQFSz9d8zJeh9x8sqYZ3ME46qsJg/E/ckBTgE/XoITEVoe1byxPcRxU9u4RcM HJdbNjm46fkG+6n+qC5nuXNiVgaeWQsC8GC84HV/vk68FnAvEsHXKfGK4qv4y2958mkV KBHaJxOJwJ6UG7kgiCGr/r0KS34bCXQQ5mhjdoYO8JutSHbjHQEjn5CbZ2XDtvsG13ok kEy57ta3yFnL3mVRWz08w4e329LGp7P8mNn8LFDcgdbpD6gJ4eHJ89oplng4IaLSgpyS tdSA== X-Gm-Message-State: AC+VfDxQJwU8HbvKnSb0xByK6Jnr35rG71u27iAPCWm/xWtzjeL55G67 jPDN/GI0tZd1ZBmDPmfo0EM= X-Google-Smtp-Source: ACHHUZ4/H6f6wDPkQqvEkyIyDMQOYBtZJLrairbpRs6FPKaX13KVPBJG7M077kc61hEJ+Wd4uDXvvg== X-Received: by 2002:adf:de0a:0:b0:2db:bca:ac7d with SMTP id b10-20020adfde0a000000b002db0bcaac7dmr4436897wrm.67.1682694017280; Fri, 28 Apr 2023 08:00:17 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id w23-20020a05600c099700b003f17af4c4e0sm27873042wmp.9.2023.04.28.08.00.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Apr 2023 08:00:16 -0700 (PDT) Date: Fri, 28 Apr 2023 16:00:15 +0100 From: Lorenzo Stoakes To: Frank van der Linden Cc: linux-mm@kvack.org Subject: Re: [LSF/MM/BPF TOPIC] userspace control of memory management Message-ID: <4cefb151-df30-40f3-b45b-e7ca3f362bf2@lucifer.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1DDFF8001D X-Rspam-User: X-Stat-Signature: aqn11ebqkx347dxdz89d68nt8x1okctr X-HE-Tag: 1682694018-720140 X-HE-Meta: U2FsdGVkX182vdAqX8wgdzbNKT9uxwjwINPO2o7OSyEq2zHKL/8UTJFzofeddiSuLapndhRaOjeDVveXlte+tE8ItfdrcUuzzGqeeapemgphHAxl6raWFz/wcjHjgSDxhtuSmi4UAjh/K6VgdEOfDKVp3ZZRq3ZwfeO4cejTg6r8em3xW1FgOS8iPi58x2JefPRUJ6UCIA15F4gGdiMskChRwDR1Vxm+zLrGzuT9XimwhiypsXM4U/KcVLk7VLXWBAl2206ZGYkp/ENL+i5t+kO9Y56ScMFNYF8q0XuXqsCfWaINJNydc45I3nv72KibzUXP1G/LVKD+M2qvdH2YHOeswRvBspdxBmEotwOTRsH5saYFP7aCOZLGygoMrVb0GnkvCf9o1NEw92zAvu0WjoJIW341b527YkvSbvLt1/UJC6Hu6z9KctODiCGR3UlL+r2PjQj0ZfEl78KR6zcmxb7cdXYQPhkYNWAgfNoMLndGoJH2XZMNfD+Au2w16wW6j/7NskBlW6jrW8rvMcGdepdZLEzOKqezH1SOJ5Pey4d9MNMYxSJ8mCVvB/AbTaWxINEJygXzjCYEKXC0An96lJisURzsQZqf/P9QlenfmYKatuXFhEjFXCEdXCHrAvlnDOyLXPAtH/oL9YMCD/PsgEdF9waz/yqMWGCh5QeSXxFQBJuite9RtX6Uo9EJNyELPdRATSR4qmEJSXMKSn1pmn8MPISpldp/nd2y0r6esAyWoN9r7cO7m6Tfe8DVvkWs6jOUZWTrr7Kd375tKl9a6K9/M9GBGhM1829Vqxy/x09zrphe0zI332SOIvOak3X31h5YqLpvubSTJFNyyFpXofwdwRzFRFTfLy6UbXTfUaODFNaziGnZZTHOF0PCH1vw/K2hd+t8iuwXsfB6Z9mD6GsKDNJxc8gyNFuEBBvmpWsGTxF1cqR8p9jDU1PQImrfNRKPkIxRcutT0bIH90i aaZeD1zq 0Fe6TYlewrVnfK9eZnRYy14+5d7Im9xJHDkZAIuUJIJ91Os/hlVMSXEq7rj8Ew49K4uro6CNqB6RQM2C5yJIzpD8EBH06CrlJMjRHFHx3rUKK4qDiFr3uOBmdfuRpyjHUZLy0kLWdRs/DBGRGVf/UdLKzb7tw+Sd8FQifkk9tQEeyLwDKU/qhqQ82JJMiLThr8iggKRvIfYHVVJqIry519GHPVOGjLs0tFGWuAZuLc98z6nojjSzhOK6gdDfTxBIDhKuLvqrh//fwaeleyAGL+s1pyI3FzmoAJSh29ruLWJ78AeInCO3TA565EhsdtJ6hVXNM36KZt9mAEMZT5vtaqQjN0tm7aYbVpU4OXqMw2l4KyJMweojqrtbiPhNkP1RESrfn X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 28, 2023 at 04:15:21PM -0800, 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? > > Thanks, > > - Frank > Surely userfaultfd is part of this equation too? I definitely think this is a useful converastion to have, in any case!