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 9B312C433EF for ; Tue, 19 Jul 2022 19:30:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 076136B0074; Tue, 19 Jul 2022 15:30:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 024686B0075; Tue, 19 Jul 2022 15:30:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2E7B6B0078; Tue, 19 Jul 2022 15:30:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D3BD76B0074 for ; Tue, 19 Jul 2022 15:30:55 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A6C38C028E for ; Tue, 19 Jul 2022 19:30:55 +0000 (UTC) X-FDA: 79704842070.11.19BF6E1 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf13.hostedemail.com (Postfix) with ESMTP id 140BB20093 for ; Tue, 19 Jul 2022 19:30:54 +0000 (UTC) Received: by mail-wm1-f41.google.com with SMTP id f24-20020a1cc918000000b003a30178c022so10612705wmb.3 for ; Tue, 19 Jul 2022 12:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IU/UXeFEVBdT1Z9tBh2cA7PGhMoCQZDbnozYynktpP8=; b=nw5j6HumBAcfcV3dNUP0PTt7kVt+ZtNphEeY5aExb+lSJXjTe1tBUjDCnM6u4T4p8C tDSjP1pnh4VSKEZMyPB8IgpGLyolm+FfhNCwxdulwNgTqerwQKo1d1+CzJQ3a9CNey3z c3diealW+YLikremcGB+mD4mvw+wd9pSgFuVGnSFWh22KHENKNLlZ/lMqt+ZVzItx789 rdrNHsYwRb38YHUCaSNYxKaAD0DJeegExDhOvy5qiJdrwmVTY5JbF2VHxpYOZaq6VIlO ZRBYzS7HB0WasRQtQJUxmbkKNh/aaAbps61QqK8px3oHokdz7tadmI14LTzvLYMRcV2d /X3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IU/UXeFEVBdT1Z9tBh2cA7PGhMoCQZDbnozYynktpP8=; b=2r8ppaHYjP+F1aev8L1j913Q0uS5r4ZkN9YxSmCIMTSEzfwhaExKq8Vj4yLl59m9VP ULr/LLFzCG0olax7FxahetNDjloAFlZaSJStiZ+bep43Me2bEa4DFnjQnfa0dovlofrL KB1jiFUxsrdfksDbKpWcKst1fX6jrniyx2OZtbrSPlMsDslP0Kk+qsvvELkcd/G6Rt/V fqFD3kZELTKyPwPdKKB37RBHG5MCDHQqC3sigKhpIkShM9kQNG4BzKr/9vnk2DmR70zK zqhIHjE1HEtiX8kJzchM77EvnONL/iNeFCJD+gQ9VYG/13wjOBEY4ult3q5TOdIJk00j fwsA== X-Gm-Message-State: AJIora9pMMeNQvO4azlluoD1oyoDaVJBtQnrqx4XVpA0+p0vVcShM3Ci ir/F7CmupbqaLktLZmqcWOcvxhSCpjM/jCFKMOM4eA== X-Google-Smtp-Source: AGRyM1t+urgwgqhfDqApEhoJzupTlWCjtPAtECd+qIo2VZ0WxF+HWQ6yvgLlyiTk/ABdUHbvJiAhAifSHYi9wB6FV6I= X-Received: by 2002:a05:600c:1e8e:b0:3a2:c1b4:922c with SMTP id be14-20020a05600c1e8e00b003a2c1b4922cmr745201wmb.24.1658259053522; Tue, 19 Jul 2022 12:30:53 -0700 (PDT) MIME-Version: 1.0 References: <20220712043914.pxmbm7vockuvpmmh@macbook-pro-3.dhcp.thefacebook.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 19 Jul 2022 12:30:17 -0700 Message-ID: Subject: Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.) To: Tejun Heo Cc: Mina Almasry , Michal Hocko , Roman Gushchin , Yafang Shao , Alexei Starovoitov , Shakeel Butt , Matthew Wilcox , Christoph Hellwig , "David S. Miller" , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , bpf , Kernel Team , linux-mm , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nw5j6Hum; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658259055; 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=IU/UXeFEVBdT1Z9tBh2cA7PGhMoCQZDbnozYynktpP8=; b=TovpY2cY1MEm0OqFpfaR7uY2UK4icLwu9TCvAPpz7/mLitBBZbnJfVaJO7DcbQr007aqOt vj+F/1lVxivFcEhetZj1MC6FzD+WkwTm6MCEotePnJc354sPkmRzeINLOEMvvdRyDj+IO7 M2H5K5jiVK7QVBGhmZRWtzWul/4bAmU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658259055; a=rsa-sha256; cv=none; b=R9QmXraFEwkjei1gDzpdwQOVzSroHTXGOiYoMp+Pdah2wTzQYnJ5Zqv1T7H6NOXUBheSHe Pcv+z2U/3DkLIifznDBeFczMXnsYEuxlXKCUlanLOH/u01PQ6RBiBVnxtLjR7nDF00rVwp X4fvbHYbq2VymtS+Qk+bGHMViuze21I= X-Stat-Signature: zt947hrn5hkt3g4hj6mf4n1p4cd1ad1u X-Rspamd-Queue-Id: 140BB20093 X-Rspamd-Server: rspam08 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=nw5j6Hum; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspam-User: X-HE-Tag: 1658259054-142507 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 Tue, Jul 19, 2022 at 12:16 PM Tejun Heo wrote: > > Hello, > > On Tue, Jul 19, 2022 at 11:46:41AM -0700, Mina Almasry wrote: > > An interface like cgroup.sticky.[bpf/tmpfs/..] would work for us > > similar to tmpfs memcg= mount option. I would maybe rename it to > > cgroup.charge_for.[bpf/tmpfs/etc] or something. > > So, I'm not a fan because having this in cgroupfs would create the > expectation that these resources can be moved across cgroups dynamically > (and that's the only way the interface can be useful, right?). I'd much Is there a reason why these resources cannot be moved across cgroups dynamically? The only scenario I imagine is if you already have tmpfs mounted and files charged to different cgroups, but once you attribute tmpfs to one cgroup.charge_for.tmpfs (or sticky,..), I assume that we can dynamically move the resources, right? In fact, is there a reason why we can't move the tmpfs charges in that scenario as well? When we move processes we loop their pages tables and move pages and their stats, is there a reason why we wouldn't be able to do this with tmpfs mounts or bpf maps as well? > prefer something a lot more minimal - e.g. temporarily allow assuming an > ancestor identity while creating a resource or sth along that line, and to > add something like that, I think we need pretty strong arguments for why it > can't be handled through cgroup layering in userspace. > > Thanks. > > -- > tejun