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 A1AB0C43334 for ; Tue, 19 Jul 2022 20:29:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25E456B0071; Tue, 19 Jul 2022 16:29:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 240356B0073; Tue, 19 Jul 2022 16:29:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FE466B0074; Tue, 19 Jul 2022 16:29:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F413A6B0071 for ; Tue, 19 Jul 2022 16:29:18 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BBA3F802A6 for ; Tue, 19 Jul 2022 20:29:18 +0000 (UTC) X-FDA: 79704989196.05.2D9E372 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf04.hostedemail.com (Postfix) with ESMTP id 596EB40067 for ; Tue, 19 Jul 2022 20:29:18 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id r186so14525260pgr.2 for ; Tue, 19 Jul 2022 13:29:18 -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=E7QI4chrb95A+lfqDE3Gr++Mecj38UYUtwYRCtLQ3Io=; b=dDASEWftANcWPA68mA6v9t1UAwvek58z7jMRi32IoZbby1X+Ge2rZMPmQy5K4zw/tP v4jT+6qFRjFOjZ8xaFECgczQcG380/atE2VdNllR6/TIP30/He7eiY0SlFdHSTLPFgv2 XXIFhjY6ypfsXS7U9eH2/vFfXhXMJkIOTHFeQqoGVre7y197zejpoTEnYrmAM4Jl+Vz1 5bQhTNWY2sT28eXX/7K3Ropv2nsAhL0L6o7nYviRWxO75IKkctCB1ZcHLKUFlm9weIal /yqS7FeGiNq7ELDMMiGMyys5Edfrxk7LF8QMXDQUXgejbWMa64RFdifPiz17YJgM8iOv wixQ== 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=E7QI4chrb95A+lfqDE3Gr++Mecj38UYUtwYRCtLQ3Io=; b=498F8ZhzG8P1CSQDNpL7WcoKQGG9ChRm+AYVWihipEOqxuep8PbmgVnOfJK8iEF9hu 7DELJq7pFkj713HWSZoDR+pQlxvwWABpcR7SbBN11GlyO8YrOfUL8c1oXh9+AC2iyGdW ugdfLtBz2rLxiUM2tT2LrmaI8uOA2XxX0UV8VJbJRWQNk06xi8aSpLcK/+4s03rKN/1u mkMu0HPW6IfcUIm4ytj13kz2dDKhoxKpwThJcPKqgCyCnQZ9p/7n69ILn5r9eUoGjYVH PRgqZ/Vy9esGviE3O+XQWV7i4hcXB3/sGPeUeYVyjW57/qinMew4yrB0yo90exfZAWLP XleQ== X-Gm-Message-State: AJIora/Vw8KwZ21WpMB3720r860G5P37rnKJNyLOGoinF5K0a9eyB2nZ tnBRlmgQ4lR8CCi6s4tdlwQ= X-Google-Smtp-Source: AGRyM1sZjD4k7AvJtFCsSvkiTX9qTMF2ZL+c8xxKL/W6LyQYixrn9npsVnYmKKKjYEB2Vd/6fDxOPw== X-Received: by 2002:a63:6:0:b0:419:7b89:69ff with SMTP id 6-20020a630006000000b004197b8969ffmr30273431pga.442.1658262557178; Tue, 19 Jul 2022 13:29:17 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:f3dd]) by smtp.gmail.com with ESMTPSA id x126-20020a623184000000b0052b8240840dsm3381912pfx.145.2022.07.19.13.29.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 13:29:16 -0700 (PDT) Date: Tue, 19 Jul 2022 10:29:14 -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 , Johannes Weiner 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=dDASEWft; 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.215.180 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=1658262558; 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=E7QI4chrb95A+lfqDE3Gr++Mecj38UYUtwYRCtLQ3Io=; b=24NMouzpiCNLai/gAHLQmwyAXeUEgXFpCD5CcFnx/g7T+sWohQSFzMhSxih5mdNBRUwwED 8L8XcyWwQC28kSxV4xA6LAUCtHvR7dPP7+JWtOwO+tDPukNak3u/1iAoMAStZ/VZypbMeW 68DEo1jbxi9WcdTq1RRQQ1T/dt33ra0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658262558; a=rsa-sha256; cv=none; b=OPmDkSmZTaRsWWbR3JbQo2hII/Jxrm35Yo80I2gNGLs3GQOjxuy5T5zffxviPfWPzUnOVh ejf53PEPDAMXoBzzlCpSm4k2xW/rCDBTi9AmXQfNjmWUtQcEHWMaFTuWO/m5RcRBjw47pX JxW4oSmdH8PEyvVPk8WZZcB4kUnOGbQ= X-Rspamd-Queue-Id: 596EB40067 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dDASEWft; 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.215.180 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: gwfoj1pxwnfxwcxw6xf8wy3b7fytiezg X-HE-Tag: 1658262558-635948 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 01:16:02PM -0700, Mina Almasry wrote: > I think I'm flexible in this sense. Would you like the kernel to > prevent reattaching the tmpfs to a different cgroup? To be honest we > have a use case for that, but I'm not going to die on this hill. I > guess the worst case scenario is that I can carry a local patch on our > kernel which allows reattaching to a different cgroup and directs > future charges there... If it's not gonna be dynamic, putting it in a writable cgroupfs file feels awakard to me, prone to creating incorrect expectations. > > 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. > > Actually this is pretty much the same interface I opted for in my > original proposal (except I named it memcg= rather than cgroup=): > https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@google.com/ Right. Hmm... the discussion w/ Johannes didn't seem to have concluded, so continue that here, I guess? If the consensus becomes that we want to allow charging resources to an ancestor, I like the the mount option interface a lot more than other proposals. > Curious, why do we need to check if the cgroup= is an ancestor? We > actually do have a use case where the cgroups are unrelated and the > common ancestor is root. Again, I'm not sure I want to die on this > hill. At worst I can remove the restriction in a local patch for our > kernel again... First of all, permission doesn't capture the whole picture due to delegation boundaries. Maybe we can use the same perm check as delegation checks but keeping it inside the subtree seems simpler and less confusing to me. We can always relax if necessary in the future. Thanks. -- tejun