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 A4B68C77B78 for ; Thu, 4 May 2023 18:47:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C44E96B0075; Thu, 4 May 2023 14:47:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF4F86B0078; Thu, 4 May 2023 14:47:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE3E0900002; Thu, 4 May 2023 14:47:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by kanga.kvack.org (Postfix) with ESMTP id 818BC6B0075 for ; Thu, 4 May 2023 14:47:55 -0400 (EDT) Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-24eab83867dso812982a91.3 for ; Thu, 04 May 2023 11:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683226075; x=1685818075; 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=k8jFgFNzrfMCwUIuzxfRI/Nd9VXx25M3K2ZPAn9Uf20=; b=QVi5wQAFDYiNBVY+phJQr2FzPt5mLw8QgJucpJzbmrEujtmJfrFkEYgiKGNLbNDkuB e5ENsJ37CbCAaaixkRJ4KgEQwT6+IJwCno+Pt0fF0KBQfYmFYSEg3Ojzu57OyJXLfFM4 Mp9byFrZVYe5tSKmTc+n6u0TgQ26H0pTrZaE/ja+vBm85EeZWYEVOPD6ojdDXge/M7jd P9TcQx15S2lMeUpOlUoUARjuxbmmjcx6mOIintQxhBQ7V9XxMzaQn9W3sT+66cA+TwWS CNpUjid7L/He38NtuVpb+39JvKxql63gEuuTbTAp292jENSq0GVU+j6bM5w3eCwXUs59 XF1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683226075; x=1685818075; 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=k8jFgFNzrfMCwUIuzxfRI/Nd9VXx25M3K2ZPAn9Uf20=; b=HpTTWhNeF37ItNmN8JtXSJcM/iNDK2slA/67FBBIC5Lkde/4phBA+ePH/LUawEjVaB E46oHwFA8FImHKMfwog2ziXpxQLT5jSqJoDH+rImzLgcMUXw/jln5t9H/WwROD3bEg0Z kQVkDj9rGAYjoimUdikcbBZtxzY9cj23ZcaJ1m+T7ytPv6T4reqxZdB5qaqdA7hBjVEM 2HSrRm7uWhrz32pLICxxwxwuddnGwvB8VhvPs6VSQ6CPy8NVPDHlZiRaCsV1SRR4ohBA j8pqqWlkFev/KKDFYW/lYhulZigRsh3dSeFpXhVTeIJBeQHGby7q6aZwSl5UGNIs7GnT x8vQ== X-Gm-Message-State: AC+VfDwu/mtzjDJ2mpNFvw/hufxRwCx1deAh39y2/dlHCl5GDpnfhaB7 LodB5qQ/jDt3YEHfeyIkES5COBvkPR3eDNRgdrCKrQ== X-Google-Smtp-Source: ACHHUZ4X+cFHx9v7UMO8wKI3RkxcSAswnee59uCAKEx0eosynJOGfhaPrOdwCUq+70WlxtXZibGa12EOMUtNe1nwIhI= X-Received: by 2002:a17:90b:4a4f:b0:247:a3ed:63b3 with SMTP id lb15-20020a17090b4a4f00b00247a3ed63b3mr2858158pjb.31.1683226074557; Thu, 04 May 2023 11:47:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hao Luo Date: Thu, 4 May 2023 11:47:42 -0700 Message-ID: Subject: Re: [Lsf-pc] Fwd: [LSF/MM/BPF TOPIC] userspace control of memory management To: Michal Hocko Cc: Frank van der Linden , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, LKML , bpf , Yu Zhao , Alexei Starovoitov , Song Liu , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: On Fri, Apr 28, 2023 at 7:18=E2=80=AFAM Michal Hocko wrot= e: > > For some reason I cannot find this email in my linux-mm inbox and I > cannot find it in any archives so let me add linux-mm and lkml again for > future reference. > > On Tue 28-02-23 21:20:57, Frank van der Linden via Lsf-pc wrote: > > ---------- Forwarded message --------- > > From: Frank van der Linden > > Date: Tue, Feb 28, 2023 at 4:15 PM > > Subject: [LSF/MM/BPF TOPIC] userspace control of memory management > > To: > > > > > > 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 > > _______________________________________________ Please allow me to cc bpf mailing list for visibility. The idea seems interesting. Hao