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 15FF8C43334 for ; Tue, 19 Jul 2022 19:54:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 908BE6B0071; Tue, 19 Jul 2022 15:54:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B83F6B0073; Tue, 19 Jul 2022 15:54:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 758526B0074; Tue, 19 Jul 2022 15:54:17 -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 657926B0071 for ; Tue, 19 Jul 2022 15:54:17 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2C2651A0375 for ; Tue, 19 Jul 2022 19:54:17 +0000 (UTC) X-FDA: 79704900954.10.B4B65B3 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf04.hostedemail.com (Postfix) with ESMTP id A773240066 for ; Tue, 19 Jul 2022 19:54:16 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id a15so15800266pjs.0 for ; Tue, 19 Jul 2022 12:54:16 -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=HZeKwLihEEt8Gb01cRA+F22Oe66cky6WGiN3/LkMvdM=; b=SqyAuePLHE8SDIZJ3Nm/v9EV8krbC81ZNmrSMnDfT4xydCrWNyl/4+unSC5Ask4Akt n16eU7j8Blg6jqKy9DU/xH/U1dxFTnBySPDDNXSxXehQJRJLJ5+PNFYavMnnipRIpmDa XpEBTf+uNYONzesS19OnuwlA7JBL3A0EnVIdP+0+xkjXrzDGSUV3VreDnZEaM3gyT4nJ Dg5NkFhFnta01uGUUA22G98J6Fq3VbzSTsUWTPO4ZHSQHi4ThWs+m0RKcbtxez2Lba4B 7U7o3WSN0PePBXQCv912BJPJINrhyDluIjnFIKnD0WppHImvNvvcBMdktiS0Nz96gzy7 4ywg== 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=HZeKwLihEEt8Gb01cRA+F22Oe66cky6WGiN3/LkMvdM=; b=k8cgQP9CgbC5M7w1gH8tC15Sjh7Pvvp9lgtm6ld8SWv4SBUhpoojHAhEZkV95zvYWm fVMXpTDR7BMLTgdnX7A7rQ1TF2pUdmCnLnxl6mR9B4ZBrXF6fpqohewLRGDVvva8vfBA 4hrxHjRPm585g7Qad4rYsHlH4Eqc7jUOUWHREyRAr+mrZUoFZo1VbF4FRS2rzW1/xnAn uKg9vwkuqLsIUVGFJkhwBy+sYLsPb7vv9U37fDRgh9lZ2r1bR5fF1sTbhpdvbcfoeyeD Gj6Vdjruv1oQzR13Gq9uDylTKow3kmq8yRCF9BditnOZyfY5dZ+se+EGkqYcNjepnfKa xMbQ== X-Gm-Message-State: AJIora95x7DKrIZAy/HrPCxPRVkpG5JO9x6oZwPRDgyLf+DEHUPhH6O8 if68M5DLNeIS+zLLJYAdPfk= X-Google-Smtp-Source: AGRyM1u6OR+3VxsW2ww3rLIXuKixdZTEWQ7s9wEuuiUCiIIMIErVMkNlFHdnYIDYYF4ueT3n6i2WOA== X-Received: by 2002:a17:90b:4c4e:b0:1f0:48e7:7258 with SMTP id np14-20020a17090b4c4e00b001f048e77258mr1091191pjb.223.1658260455565; Tue, 19 Jul 2022 12:54:15 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:f3dd]) by smtp.gmail.com with ESMTPSA id x9-20020a170902a38900b0016c0c82e85csm12065497pla.75.2022.07.19.12.54.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 12:54:14 -0700 (PDT) Date: Tue, 19 Jul 2022 09:54:13 -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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SqyAuePL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf04.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658260456; 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=HZeKwLihEEt8Gb01cRA+F22Oe66cky6WGiN3/LkMvdM=; b=X3L2GAeaVGy3cnD907lF6tU4xPDHSXlzmlLoo+LQKACVosgZMl79TU5gMQevf4NBL60U9P a2WdeN0BKOj8jv8j7uSrKUqTsBWasbprt8PapjCH6Fd7Hs2AehdgPhe2xEcRR0+R5pzR2p TxLlFHcZbeYB4r4K7y9XPc/Oq6J0Z1w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658260456; a=rsa-sha256; cv=none; b=Y7YNV8fB4TWnWnkeqNtEDeY9bJBtvw51XABaabXsBBtQd6KMrRnypFyy+JvnyHIhqFbSyN IazK9vIpW3DcliQodMrVKJKaiQ+68GcQQ8g9PGQ2GpoNL+VgyLZrIdHH1hbzBxNFFDV3ZB xqxYz/hwG0wqHYPxVZimRa3cw9MyZLI= X-Stat-Signature: cbna59qd84kyo6s96t58cb61x979dbc3 X-Rspamd-Queue-Id: A773240066 X-Rspamd-Server: rspam08 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SqyAuePL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf04.hostedemail.com: domain of htejun@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspam-User: X-HE-Tag: 1658260456-833227 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 12:47:39PM -0700, Mina Almasry wrote: > Hmm, sorry I might be missing something but I don't think we have the > same thing in mind? > > My understanding is that the sysadmin can do something like this which > is relatively inexpensive to implement in the kernel: > > > mount -t tmpfs /mnt/mymountpoint > echo "/mnt/mymountpoint" > /path/to/cgroup/cgroup.charge_for.tmpfs > > > At that point all tmpfs charges for this tmpfs are directed to > /path/to/cgroup/memory.current. > > Then the sysadmin can do something like: > > > echo "/mnt/mymountpoint" > /path/to/cgroup2/cgroup.charge_for.tmpfs > > > At that point all _future_ charges of that tmpfs will go to > cgroup2/memory.current. All existing charges remain at > cgroup/memory.current and get uncharged from there. Per my > understanding there is no need to move all the _existing_ charges from > cgroup/memory.current to cgroup2/memory.current. So, it's a lot better if the existing charges aren't moved around but it's also kinda confusing if something can be moved around the tree arbitrarily leaving charges behind. We already do get that from moving processes around but most common usages are pretty static at this point and I think it'd be better to avoid expanding the interface in that direction. I'd much prefer something alont the line of `mount -t tmpfs -o cgroup=XXX` where the tmpfs code checks whether the specified cgroup is one of the ancestors and the mounting task has enough permission to shift the resource there. Thanks. -- tejun