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 A72A2C43334 for ; Tue, 19 Jul 2022 19:16:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A3686B0071; Tue, 19 Jul 2022 15:16:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3544B6B0073; Tue, 19 Jul 2022 15:16:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F5066B0074; Tue, 19 Jul 2022 15:16:39 -0400 (EDT) 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 0D8286B0071 for ; Tue, 19 Jul 2022 15:16:39 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DE0B01202B1 for ; Tue, 19 Jul 2022 19:16:38 +0000 (UTC) X-FDA: 79704806076.20.73825F7 Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) by imf05.hostedemail.com (Postfix) with ESMTP id 8F38910006E for ; Tue, 19 Jul 2022 19:16:38 +0000 (UTC) Received: by mail-pf1-f170.google.com with SMTP id d10so14466696pfd.9 for ; Tue, 19 Jul 2022 12:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gZmfNWIcwpYUn9IU6g2nzINZr3xWHYTQQ2xLd6CYUDk=; b=b0J5XIP1mnC6gW4uvEq1x8/XKtFs5GFnw3RVvilDUPS4G3rvquFIRH6pSjvW8owHIh 8h7oFg4dGXilCafp9/37EhpB16kGehixd6Q/3yAYGo6PFO2YNp50+Jbc6tfIu9kvHmEZ HiMpXY/9MkF/2OgCG9QW/kJMxBAJcOh4q53MH4uS2/9teuw0eEcyPYWCBPYnODekMpz/ GakPxJoPGFmlv9fFX9YEY5oxRdcHFQoEJcxh/btFthGHebblE6sGYKJuHWld6KozKYFr uThOkstQIoduYMs34e44PZRXXdzrypNmgkC9x0d5S3Vicm0S2vMdr7G8GA6h7k6kNbiq gTAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=gZmfNWIcwpYUn9IU6g2nzINZr3xWHYTQQ2xLd6CYUDk=; b=ZKtGHMS9ADRzVNSnOsn3q5VbZKtNT4yiS8sMO5LKZwmkfMiNSpCqogrn1B8NOBGKTs Y5uxbyCtCYiNHejsMehNnKkK+zXYLRed9fejHaez16aPD4V50VBZ91+kqGRNTGRPd3tE 5/XTiRt1I+ZnW65MBZ7NUai1/XGCnbf4xnbo8YPI8D4fXXoX68+HQH6r8MGaNq0T+MAf 3DnZIJ9DOknOGq6g5wQjCkyX8SJ93P7Vx9ZpA9CV1UORA9fr8zW/VL2nlYWfTXKZ3vWK oopaLp4b4GT7WD/i4ZC0mgBW9WOZ5BFJFLAZYcLl/SQpvjuuW38Z/yvw5+V/gUlubl5m fLPw== X-Gm-Message-State: AJIora+Up8+wcuRvA7n6z/3YMmFDYRvdOsIohQ7nzair6EYXT5hVznJw inXl8cp6NFgjJzyf93mnO7A= X-Google-Smtp-Source: AGRyM1tLL40fABGIJwyWDAsGPIx9WI5RQcJWsOfijr+6dzK2N5YFDE6t5Hv08w4BVR/pMg5MOx5hbg== X-Received: by 2002:a63:4a06:0:b0:419:f141:888b with SMTP id x6-20020a634a06000000b00419f141888bmr19558210pga.55.1658258197034; Tue, 19 Jul 2022 12:16:37 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:f3dd]) by smtp.gmail.com with ESMTPSA id m1-20020a62a201000000b0052ab3039c4esm11969183pff.8.2022.07.19.12.16.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 12:16:36 -0700 (PDT) Date: Tue, 19 Jul 2022 09:16:34 -1000 From: Tejun Heo To: Mina Almasry Cc: Yosry Ahmed , 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 Subject: Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.) Message-ID: References: <20220712043914.pxmbm7vockuvpmmh@macbook-pro-3.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658258198; h=from:from:sender: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=gZmfNWIcwpYUn9IU6g2nzINZr3xWHYTQQ2xLd6CYUDk=; b=BH/TR3wjnDv8CrOSMqjLpQnpFwN8LquBBC+9fuxLRqjbTLQJ0WBwH2Ywo5sqYCJTVTKO85 G8+4ezXceqW2ES57lqCo2HZVXuP1MVNI1HVGinzG++wuCW3L8/1aerGCj4GLqzR/E2i9C2 oPfo8CwIz2AAOolOsa/j6g0tI6J8mY0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658258198; a=rsa-sha256; cv=none; b=hEPyRDCC79S+j4fN0G5iO+Lh19tT104ANPSwYv8K2n05yV1WHLjvWz7N+Eqqo8y70WvbDg fDPwUQGbYvVig3+HwSHSEeIJXepKG542SNR8TrEF0oCZxnENHaaXIEx+5vL9ApkWgjDRN1 Zw+PdQyxeQ9MVrFCA1i7AFoAJ71qo30= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=b0J5XIP1; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf05.hostedemail.com: domain of htejun@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspamd-Queue-Id: 8F38910006E Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=b0J5XIP1; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf05.hostedemail.com: domain of htejun@gmail.com designates 209.85.210.170 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: tun45mtqpdzokwt5zixausr7imo3awez X-HE-Tag: 1658258198-474796 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: 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 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