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 68805C43334 for ; Tue, 19 Jul 2022 19:38:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFEE76B0071; Tue, 19 Jul 2022 15:38:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AAF0A6B0073; Tue, 19 Jul 2022 15:38:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 976506B0074; Tue, 19 Jul 2022 15:38:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 849056B0071 for ; Tue, 19 Jul 2022 15:38:16 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4FA89120339 for ; Tue, 19 Jul 2022 19:38:16 +0000 (UTC) X-FDA: 79704860592.27.1944B96 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf24.hostedemail.com (Postfix) with ESMTP id 0051418008E for ; Tue, 19 Jul 2022 19:38:15 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id d7so1065820plr.9 for ; Tue, 19 Jul 2022 12:38:15 -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=W+bw1rlqP9bD4CtjQLvqFHkrkeNIImEme6vPKqZseN8=; b=AYpp0Vt0Bv9VuFoChdGVsrFCOom55Urf9sSrftgnLYKEpbsIJqWtC8N/Dg7QjdcbNI 2SLCTKr3XqtefnEeHZtdFxsc+YNsqWCy/EB2EmE8c0TuW2k0aptW9KCtN0t9taMO2lq7 +hZpwV0c3sKBW3Y7mgALTX/pHhgn0TCNuBnczUBLp2p8WBWkXIODkV0JJpPSNJ6FAweZ XbF3bG56Z+ly8JKCtgoz3LUycQkFl4tcVgUjJp0sjATG9sPTgoHjLL7hcqqVEhDIsblG liRHoz1ni+9hsXAkYombJ8nRuIcR1Ae1Ym/erW34sFyDfPlHp7fcbMO3+EqRHDeTccEh sPig== 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=W+bw1rlqP9bD4CtjQLvqFHkrkeNIImEme6vPKqZseN8=; b=FGLmXoTzRLyYeZQVPrageYZLR0+GofqoajM2fhF8zWfAX0WpsBNO5nAx0CrCayHo72 dkFFuDSnKj5Jh9dYAAAEXf5goerEolU+46Cp70/oGoWwSc/mGZr1S7Xs77baZFap9OzF zANTQ7dGm1e89/3lBnaKQBhFeZcoCEIOGPHpdlINQrTfKWYPyxVpYmRvgrRKX0y26UzB +xDcdl1FDctLZtqImjVX/gJlWZ7EAxY59SQwcigsFShKhNyaaf4n1EmIMLKHH9pccgkv mrWHTGmCo3oM4yKMD+Cz43NP0qDsX1Xvnape3F0b5q5/KKA1zy+U59TvROMLr+g17SWI nHqg== X-Gm-Message-State: AJIora/MMb8IC4+HJ5mxeY9AC92SEWlPYfuPL8gwyzTVWxJy8IQ86Bsb 9ga/i0XUCAjWUSKoNm7j2RU= X-Google-Smtp-Source: AGRyM1t2wshx0Aa95sgGeKHlgBm4LNaZDZSN7wWNveJD/9qnW7Kf7GH/CKJaIkpAGXNHAGva3Ki7xg== X-Received: by 2002:a17:903:2344:b0:16c:4331:e5da with SMTP id c4-20020a170903234400b0016c4331e5damr33941382plh.138.1658259494710; Tue, 19 Jul 2022 12:38:14 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:f3dd]) by smtp.gmail.com with ESMTPSA id i184-20020a626dc1000000b0052859441ad3sm11844908pfc.214.2022.07.19.12.38.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 12:38:14 -0700 (PDT) Date: Tue, 19 Jul 2022 09:38:12 -1000 From: Tejun Heo To: Yosry Ahmed 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 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; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AYpp0Vt0; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf24.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658259496; a=rsa-sha256; cv=none; b=clajmrDlnkP8KposuM+MAN2lybK/4qGEsSa6b7EvMQFJJoD2L94s3tJXvUKAnXAUplnsdw pTRTo4oIi/sg8/rb3R+WpRGJrhgtVbJFKKepOFM1b9pSBKJKsF4+1nnmtx+Dpx5WoYrIU6 TWX9JUF54W0TrLbLnmxEpjm+UrD709s= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658259496; 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=W+bw1rlqP9bD4CtjQLvqFHkrkeNIImEme6vPKqZseN8=; b=IkKQJP7tRCMs9aGjJxvkDREfh6AxFNrMaZYx/rIeQPalI1Nayn8NVVBXhSLgdXErFZJxsn wUZqzauzTKDAFpb77G4cs3EVwAiD0qJZAA+mXovTGoZKq6OmSIPRIM8tGHymXR9HG+Ud+I y4dMDccatviYBky9lnHHe4lqDp607Xc= X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 0051418008E Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AYpp0Vt0; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf24.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Stat-Signature: uqy4kcnee4zu5rdjsu7h3yiochc35zuw X-HE-Tag: 1658259495-856057 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:30:17PM -0700, Yosry Ahmed wrote: > 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? Nothing is impossible but nothing is free as well. Moving charges around traditionally caused a lot of headaches in the past and never became reliable. There are inherent trade-offs here. You can make things more dynamic usually by making hot paths more expensive or doing some synchronization dancing which tends to be pretty hairy. People generally don't wanna make hot paths slower, so we tend to end up with something twisted which unfortunately turns out to be a headache in the long term. In general, I'd rather keep resource associations as static as possible. It's okay if we do something neat inside the kernel but if we create userspace expectation that resources can be moved around dynamically, we'll be stuck with that for a long time likely forfeiting future simplification / optimization opportunities. So, that's gonna be a fairly strong nack from my end. Thanks. -- tejun