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 4874BC001DC for ; Thu, 20 Jul 2023 22:12:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 901DE280167; Thu, 20 Jul 2023 18:12:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B1F928004C; Thu, 20 Jul 2023 18:12:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75262280167; Thu, 20 Jul 2023 18:12:04 -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 6683C28004C for ; Thu, 20 Jul 2023 18:12:04 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2482FC02E3 for ; Thu, 20 Jul 2023 22:12:04 +0000 (UTC) X-FDA: 81033388968.20.2621BD2 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf20.hostedemail.com (Postfix) with ESMTP id 2F4301C0022 for ; Thu, 20 Jul 2023 22:12:00 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=NA0WXFjj; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf20.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.174 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=1689891121; 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=Yyk+1akDqEk5I4HX+iaGF6X13C0u0JYMqRauqkNOe8U=; b=hptjbQOSbsShqH6h/Ihivky+VjybSU0d/hHO7N77o83wI/fmiXWBDXAK4kBZzg3qEcj3M6 Bwk/eksswH4i7IxlrGxKlJ8lOo2ibBQVB7J2xWn/+m1RisgGQK0LYgpWppph6wyKTiGjsb /o9tSc3nEcz/Lp+qrXoiU7j8+J4LrdM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=NA0WXFjj; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf20.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689891121; a=rsa-sha256; cv=none; b=C8Mfh4gnZk5wTU+N5Fqb0nIeHn1DP8J5+8zuzQmoaqQjlOAM/xUdu8UutDp9JwfJo6Vw5g g4P/wIgzz7yZAWE9D4hEtSQ1bDK5mNbav7tPUP9K4Gfr/3oGFL03gthq46PfgSVl0hC0DP qEK0j+j0Cx0TEukGoj1LpjcDEo0h4OA= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1b895a06484so8746815ad.1 for ; Thu, 20 Jul 2023 15:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689891120; x=1690495920; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=Yyk+1akDqEk5I4HX+iaGF6X13C0u0JYMqRauqkNOe8U=; b=NA0WXFjj0OpKZjyiDZaTzkQ3U0kUE85I86+6zcqR7zjTAjF17ktJr20AQoERxT02kC 2fR/wGnihnbW7LuV1LCk6+1Q4OEhkBDZdXqa0IdN4HU8ynq+somylkYx14dr75Fx24k9 CLBBCw7T3bJnCIx6Tr6zC2NqMGPq6pZ9oJLN8x9DS3fpqLvCo4/DxwBYqyOwzbdOyx5d XjbJleeCani28OQgN52POgHzpVfc5CqvCXovkl8WTPLRoOY2bBzjcLqQs6faAVYdXr5B nHATugm7zOyFNUl6WNEG6XkwJYQZUk+lNHVxDGzZ7zReCzBrHKbTxHmsauvt/8JV6eKR IWMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689891120; x=1690495920; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Yyk+1akDqEk5I4HX+iaGF6X13C0u0JYMqRauqkNOe8U=; b=H5CYL7vdfBkNDr71u7LzBw9tz/WJCXtFFKG8AF0NePUw1ZA0/qj90588u+ICvliL/1 sAZdRKPs+tgKEsVwyPuaPnoXEKhH35rCbcPz9SoPUJG86p436C05FMZEOkQBgZ3lshWh VJgvh1x3MMlUNmovOhCMdjrXXNnI+ZZ454t5n2PNRi5E3rSqbhgz2LHitWU/Q6kc6jwR 16xZnCtvPX2lbm+gnpvoP+tjQBSgvt63JVpIni4vof46eHvk/+1L6mKqYuTW5jyGhJfC ICvnWYJ+v1wvxp57pu+mEomvhmbvK9gD0G/VYH2NCYhaiwVJlvGBfsOODoJdF1k0b4h4 24mg== X-Gm-Message-State: ABy/qLY1kg7+5TvOlLTAdFJzTUhVvI5pUuqO1+zXkApDzseyOjarCGpM UjSzUgUjOHnLAaDZxTe1oWM= X-Google-Smtp-Source: APBJJlHX/VJZM2WUkAygJroxRsEzFx60munEJlxZ+ORzKpaCGbVeOKOwwPh9c9YlNyCbqHDL+x1gNw== X-Received: by 2002:a17:902:ec84:b0:1b9:de3e:7a59 with SMTP id x4-20020a170902ec8400b001b9de3e7a59mr381057plg.10.1689891119647; Thu, 20 Jul 2023 15:11:59 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:fbd8]) by smtp.gmail.com with ESMTPSA id q8-20020a170902b10800b001b8baa83639sm1891440plr.200.2023.07.20.15.11.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 15:11:59 -0700 (PDT) Date: Thu, 20 Jul 2023 12:11:57 -1000 From: Tejun Heo To: Yosry Ahmed Cc: Johannes Weiner , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , "Matthew Wilcox (Oracle)" , Zefan Li , Yu Zhao , Luis Chamberlain , Kees Cook , Iurii Zaikin , "T.J. Mercier" , Greg Thelen , linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org Subject: Re: [RFC PATCH 0/8] memory recharging for offline memcgs Message-ID: References: <20230720070825.992023-1-yosryahmed@google.com> <20230720153515.GA1003248@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2F4301C0022 X-Stat-Signature: 3rxyp4yq8rtkfgaktpd44nofpkk5pwms X-HE-Tag: 1689891120-758689 X-HE-Meta: U2FsdGVkX1/NsEfq4SHhRwYprf6QIZ9M7d39eTmGaJ6c56AmL1dn14spCVzhIZd/4rB1YGZONluSKeJ55KwPpQd1IRSfIEuO1H9XlbJcngtSd1iBz1NbST7M9vf4uuphLdqUVukE+O2I5P3zgE26a6n0osAA3719jZ0cQSUTLptzEZaenDU2XMIRvR7e7BMHzL8Y5OQFb35YbI0JSfVx+AHzxCsxXCKFveZEmZAjO6hz020MGYaO6FUjmPt2WeOjhxN/u0aRyv6Wt5cpU8rfE3CwqAnCSHU0XrE2arnPW7nGMtsbyMahgPT8HD952yHaOZJ5HM7FV60TvpkRB2vk7Assmm+/WqT4vxQjNJkgNeJmk6x/DMpmhJVSENd7Im7vk6cGW59emX5XRgjlOsw5dEBGH5k5B7j7Pt5+H1P1JyvsrrX6Y1ZfFz3OMJX99YSIjVb4KAZtslq8lO1dKCB5sWFas0cAEjNP8ouVKDB0xpw8JJfS0r4buGAq+x+6G+UcKfUf+K/txCmlUpV1Lh6LPEx+y1AvqsNJjj+nz+xjvGnp3vyenEZLtHAE2rSD7L7AZAPTpurtV27yux+kidwgJe3MxwtTH9mWdqUzWS+4JWwPKmXcRmOwt5m8Yk5hgh+2+lRqRm2o43vzKCIl/yJskk7SnniNjwxLzbKxmtYKc+W77IknNg50XAlGSwnrOERqYrJeQaJDBbbWqwBmQQ3ZtQ4laQDRJB4rlQgeFqv6zFvaZTILI1pw91fz9fNHd/Ptp1ybD0x1zZKjgCWFk869cDNHJ8cwifSFlEeknVGYTSCdkhp+lpms7GT2LsqNvNpRESH6Mx6jKYCOn1Qv8ACgJE4H3oi9SF1zbNCG7D1JMBMytjEPW0Vd53cgxKEqEN1rFo1xSr7pAJIKkxpDM6hIJ2/JCdKuRdQblIqOmpuusm6HXLGc03pmm4INT2sOYkj92KmpUv1RxH6N7Q5g4Y3 DDc+9ldF EjOTMf/l4+/Lrsof8qXxDR79PY8m2dlM0YNTramxZ14oMK/RjVQoshCNKmeA80m6zBen1MJ1+QG6mTLG0SK+pR7dpdppz247vrBCOxjbheuFu/8wnmvRw7OihsWJpJ8ZgLc9nDZ6J/WvpQL0eBBgd+AYS67rl7WHi3NlbYI23pZp9HEu0+ZZNiDD5iQCu8xcIZrs7QlWOM9p/hImreL71Z3YmbJjXcc8WWmaDVm687XPYK5GV5GW95JkljJ/tos/hSzZ9287LqsnuKCQv5Bx115g8sPgTX9SYOxt+EEy4j9yASOneLz+ED50CjzvOWa4sTVecmC9QTqDp86V1AguQA4Mv9iC/5nMB3Y8i3cUtgntT9iJfSpR4LlqvKIB5vqYJ6jVgLrv3X8s66zYMO4twaoe6XeWpx7wAYbhqKHl5AX65pmmvb7T0OBVsdm+FligxBV4Gk2bM3UxL+ttXKSyF4z2yKcvGrH8pXBwCB4YQCbMZkClCH/do43sVu6ECoTEivPg8 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 Thu, Jul 20, 2023 at 02:34:16PM -0700, Yosry Ahmed wrote: > > Or just create a nesting layer so that there's a cgroup which represents the > > persistent resources and a nested cgroup instance inside representing the > > current instance. > > In practice it is not easy to know exactly which resources are shared > and used by which cgroups, especially in a large dynamic environment. Yeah, that only covers when resource persistence is confined in a known scope. That said, I have a hard time seeing how recharding once after cgroup destruction can be a solution for the situations you describe. What if A touches it once first, B constantly uses it but C only very occasionally and after A dies C ends up owning it due to timing. This is very much possible in a large dynamic environment but neither the initial or final situation is satisfactory. To solve the problems you're describing, you actually would have to guarantee that memory pages are charged to the current majority user (or maybe even spread across current active users). Maybe it can be argued that this is a step towards that but it's a very partial step and at least would need a technically viable direction that this development can follow. On its own, AFAICS, I'm not sure the scope of problems it can actually solve is justifiably greater than what can be achieved with simple nesting. Thanks. -- tejun