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 8F616C43334 for ; Tue, 19 Jul 2022 19:41:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B0B46B0071; Tue, 19 Jul 2022 15:41:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1611B6B0073; Tue, 19 Jul 2022 15:41:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0281A6B0074; Tue, 19 Jul 2022 15:41:37 -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 E7A416B0071 for ; Tue, 19 Jul 2022 15:41:37 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 746E9A02E2 for ; Tue, 19 Jul 2022 19:41:37 +0000 (UTC) X-FDA: 79704869034.21.F5A7F7C Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf11.hostedemail.com (Postfix) with ESMTP id E2F3F4009A for ; Tue, 19 Jul 2022 19:41:36 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id e15so17877504wro.5 for ; Tue, 19 Jul 2022 12:41:36 -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=aqMPXU/hy5J5UT9zpbIzXR+SmaMEDpe2x0xawCu4+Xc=; b=OA15sUKR2X0chr/bQ+n2GmiKnfDbGXZm3GeDMLbos4nNcOj1PvYehwq3gxyn5O9AC/ J5nXTROb0GVX4AqQFlSuJKKDxYfWCkiYzql5P3a8EnLhM/H97610BoFlL2T9XLT1pejr gpcoaMuVuSswKkRM0VTC4ZYCNU54Rzju9G1+I/9ieqeuQe6ZWvy0RtQSM0CWmp7u9ded wecICYnWAx8a1S8LE1qQ5yLmFikwuVW54WQ9SicxhJN0L1GhY4ZuCdskOYD26r62zLiW o3vhSM638MmTELWAqJl9jjRQeuuqX/to94roy29ZmdVDSDeVoT9ZC7LBCQY2fg0QBzh8 IG/w== 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=aqMPXU/hy5J5UT9zpbIzXR+SmaMEDpe2x0xawCu4+Xc=; b=QBf6ESnJ3H+0YiEWM+d9uZu4s1l5B4bXDvZ/yWHsSbkTC7jfyWNlVQYf3z+eA3/fxa iCHSMHX5pALz2jgsNrBilZC7mkIkNxPcwmGC/8Eqw4X/VqgjnJKA1yiBhzUSQP+riDnE SSmOmrYK3bp3bA0c3cA0W8w+FQu+BjZ25lf/UVoR6q0IsHUIvddL9CEBsIH8KQRSAfZZ nr4f8585BYOb0rOKz9ibg6px1pE0nCq7u9Vz8IQ48Fn860+QhcnPT65mckhj+wetI+Ol 4Y7Mrh8gdDN79REAoyBuLx2BqvC/A7iAc11P9+1hXmVpc8HJ1NXOtddVJ91QIVoHbg99 1e9g== X-Gm-Message-State: AJIora+FvsO3GXn9EQ60jGRYuf5JHW01wWRrftki9lUYeVEbNH1huewM wclN8bQkv88gp1SFqplNASXgw5w6yUnaVUyYbY2XAg== X-Google-Smtp-Source: AGRyM1tdK6kWeAvNgfrVukdO99uXAAcU32CuU/nCYYUEoGbmfovUwPyylkBwB9waw8bPKdYlNnUKkDceMWFODZUX8P0= X-Received: by 2002:a5d:588b:0:b0:21d:a918:65a5 with SMTP id n11-20020a5d588b000000b0021da91865a5mr28572759wrf.210.1658259694984; Tue, 19 Jul 2022 12:41:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Ahmed Date: Tue, 19 Jul 2022 12:40:58 -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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658259697; a=rsa-sha256; cv=none; b=lY9jI54g5XIfBqhVbhXEuMhhoglyS73s3YDuxlt4nOb3iQmuiU+FaHf/OLQ0nQcHEylwJ7 s2G4J2Qb9haTD4bBzplNX/YQ0ywicjD3GizCJ5eZ4piPAeaIq+AzlSjHGFLACnIVuDdiQe +z/ydqWYA3daPSsGy/lDslf/0JGxtS8= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OA15sUKR; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658259697; 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=aqMPXU/hy5J5UT9zpbIzXR+SmaMEDpe2x0xawCu4+Xc=; b=59yIyLfK+x4JKBEMjJjQDUPVveRcSqO3WZu50+pu63oTUNM1GV2CBVJaOtMhRsGvCmm99W oxm71SkD7nz3AIuI8Ahprb+wWXApi3tAvUMwDz6RXdTNVPNWtPTM7K1evdm7zv6WMYbuMl Br8czV0EDbgmzMBVwGyATHjTzO6hpfk= X-Rspamd-Queue-Id: E2F3F4009A Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OA15sUKR; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 4zkjasj7w7bbgxdtj7db4rma98sqo3kd X-HE-Tag: 1658259696-4241 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:38 PM Tejun Heo wrote: > > 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. Fair enough :) Thanks for elaborating your point of view and the challenges that come with this! > > Thanks. > > -- > tejun