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 BFC74EB64DA for ; Thu, 20 Jul 2023 23:33:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E119E28016C; Thu, 20 Jul 2023 19:33:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC18A28004C; Thu, 20 Jul 2023 19:33:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C628328016C; Thu, 20 Jul 2023 19:33:54 -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 B713328004C for ; Thu, 20 Jul 2023 19:33:54 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6F434A0301 for ; Thu, 20 Jul 2023 23:33:54 +0000 (UTC) X-FDA: 81033595188.20.52DEF6A Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf26.hostedemail.com (Postfix) with ESMTP id 92641140009 for ; Thu, 20 Jul 2023 23:33:52 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=p+DjGaqx; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf26.hostedemail.com: domain of htejun@gmail.com designates 209.85.215.172 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=1689896032; 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=QDyB0fNg8iWGoLzY4kcY3n9F15g3W1rTkoIJoBTRg3A=; b=FOPDI4u5ecdl83wg4hioWHG9sDca3e8RDYJtbT/moSyI694dcWqKMmiTyEDbJJmgg1OTaR R3pYfy0EeNULZ4rOFKUqRYFC5rBJK6Bfu/cMpHboy7uhBomGDwJ6v+aK2LuO2B3957c11H 1wGTzYLWTJBKukYkJBrX1+aEeUxyQYg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=p+DjGaqx; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf26.hostedemail.com: domain of htejun@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=htejun@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689896032; a=rsa-sha256; cv=none; b=A+Rn4W1YNYCsRcD1IpkQzcWrTTrxhq4YsrPfs5pddemohWhoiQ7FUNaG4jzlSEchf1onJU AzpQTa9bHaVSLE333Vvx65mHhSAd15MKZap5pghmLXYWgXlwKY4LJ0AsClP0XNO3GpmDdG e3axfeS9p6PBUyKd6pWWdhVHJPNeZ0g= Received: by mail-pg1-f172.google.com with SMTP id 41be03b00d2f7-55c85b4b06bso733680a12.2 for ; Thu, 20 Jul 2023 16:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689896031; x=1690500831; 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=QDyB0fNg8iWGoLzY4kcY3n9F15g3W1rTkoIJoBTRg3A=; b=p+DjGaqxAYYqPCdrR2BuBFrntop3OtvaJ9VPhfM4o2gjf3vqRJipbYIu7R0l45bmex qOYSyJjyvqVatCS3/cx/jCT624c+7E64DfOD4mxB7fVWiy9qgxpagCj5Oq7t63/bbEbd 7XlvJpp22DUAqDFFOk1rUNh/4XL1OEyZ9/FICeZEWEvKrC3C2DaExZWPQbFmbi8btTih OdWniYrypHRj+r7hruEGoY+OT/ko57kNTp34phNCjotDBg6lkZQug5+DcQiRLL+PYgyn Urb767YbMH2gYYyExrPkfBmm/0ZwTrS0pZGlBY0dMuyw8WfHFCJ1y0ZDpbMza1FBy9MC D1mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689896031; x=1690500831; 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=QDyB0fNg8iWGoLzY4kcY3n9F15g3W1rTkoIJoBTRg3A=; b=ih0lnJumGcc1qOq+hDdOR6XYL3sQ+vK+tq+UrI8efEzuhR7JLyXlX0pwUkD+u2hCi3 oJRtGxBSfbMaw4b9tzz/Af4lxNOdPk8e2x1OfVznVm/ZRTdgWCaUPM9y/DBKl05F7TmG yxPKd5DzXWomxuLterUZ1V3Dx13UwUdGiRz9wAbY980/cyza+q3p/UxJQbRL7FD2oOoc Y0TiZsLdXPGN9Ob936T7iUnXwzqHS/Ej5IFFPMlmdcGo8UUH9ROpw+Bv7T3RZJwTAJE+ aaghTBvoTsWdc4YmkK2wppmlCATs4LFTv/8QmGwveV3sNWbnjyXtN73WVtGrU7irq96c Y6CA== X-Gm-Message-State: ABy/qLZeesJwNK/6mq4Q6ai07rV2GAWHA6plqSZiUgo8t3J77AnCtT67 QyECGfeB/RjLO73qU7ZfP0o= X-Google-Smtp-Source: APBJJlG9dcKPqdMMFcJVFh6rhJcaarEtkzCu++Q5F259HoJP8/SfAsOR9pG4xjmljAFXmku1B2DUrg== X-Received: by 2002:a17:90a:6b4f:b0:262:b22b:8ab5 with SMTP id x15-20020a17090a6b4f00b00262b22b8ab5mr128498pjl.17.1689896030994; Thu, 20 Jul 2023 16:33:50 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::5:fbd8]) by smtp.gmail.com with ESMTPSA id 3-20020a17090a01c300b00263c8b33bcfsm1576834pjd.14.2023.07.20.16.33.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 16:33:50 -0700 (PDT) Date: Thu, 20 Jul 2023 13:33:49 -1000 From: Tejun Heo To: "T.J. Mercier" Cc: Yosry Ahmed , 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 , 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-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 92641140009 X-Stat-Signature: ei9u6iuc6j8t7aihtrrpkhni7oc4go8d X-Rspam-User: X-HE-Tag: 1689896032-492212 X-HE-Meta: U2FsdGVkX1/5/Wv86AcnrhjjMWIzLGHRaci2QpYpxPkYeDe7YC/OJ5jgjTOvBsj4We+hS3mbGGn5FVw0otlWXfxW8gWCeU5h6/vzWGnQtrqkU1SC7DYCdOX/oFqWxZVrV9fEYCXalOmZKWARm/GDFxXgA6zUaoqA8WSe3d/j9ft/tzQhRG6VgcQhwQST9qqF+8BFT1hIR4vv5+0x0vbbhJ1oJKCpzzsvuMilUoNXkV1M9AcfkQ3DGUjhZQB1Yw635xQMZy60jwqb8vq3soPXc6ZFCPjFljxCbAZMSapWY8bvR8tx5T+j1TqBE8mc1U3s+dKf+nD7N9JOsL1sqjaNWd2J/9/vvC8zi/DPUaht7FI0nchrg9gcYoR6TUro40WqY5lPfK2u14Bgi3pEd6UvzG5jSRyHKOG88iw426dvLw8mu5+P6UaroM90yXa2T962XqPrXEf1MbpqlQRGERWNQs72aHzTFRjGrNBCbPQ+/RIf/Z/B/MR5lHhRcT0F/OCiXUgb6ZiZDot6lphhba30klS7+EtdjvqsJDreSZs8lhoA2mvKZwjRt79hqVgHMrg3h96oRnGIX4JwDgE48D5MhKqbgve1DFhw7mpasF8me16MoZGToUfN6utKhKdL4XdUW6oMJJPGgtJmSiwO1bs+ZWrUZM2JTEi1TroW0JRfK9B3sA2Ka+UobKX5jAzhSnKOiWOuHM0W4Ysa0wlpgmA0xz+YJrr1lLcDjWTavv53Hbs17fdiKCy2Bt84HuPdL5itB6TY4mZgFXiNC0/k+0+aPX9kd0nAN2d9Liid9swYIJ/fo/CQ8ZXJ+UE6brT6J1LYowU7bElLE94YSckfJok5h6n2prkDDU8r29g70B+fIDnFTgPWtlOb4+BjgHC3sDvExoR50a/XAKWBf7IRpPoQ1YLAOVKMtda2DmD+tLFiaIueQubcr/ZAGzpyl3llDpAa8jPjLbO379FcSC902gM Xu8vBv19 XMxVvl6IInolYqL3Yf4DUMNNuXHxTNdECHN6UlnOeFrnP62Owhr8BwAoB+40XPTxfiyWi0C+y2YqGLXal0BJfNG/zqjP89SchoiMNfG8WDB4FYuvvMuhx/ViFiJ1K8uEaTraLN4WbJJBjtZm8TLalYiwd+PlkO43tk0RyJTcy8tIlS0Uq8mY0r6viacc6LJVMD8Ijb3YjDGjK0QYrhH0I2iTFE963kMRprM9rqOB4pzqsM1fWxX+NHA544xk3LLwpIE2opoJfsoVChIwyiVqB2ZJjJfGnRmgOpDCEgZH72uNHdHZP8hp7ISPlMaUWICeMrs+h9qWWoYnEjDxslg6ODEaWVHYX+jRIKOGZ202NgmGs11GLH/sJCGiyPh/o2Cgxb2iUrVEh4Ux9XTS9qXoe/mZmwzdWGqSXh5fAejW3uDY0Fo22H6SHi9m4BRY2tAG1tEdhfMpsQ3EDyX9uKWH9Kgtl4Sk106ODRM418xasmDgDZqoAjF/+pjxWIsSuuDmz50xc 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 04:24:02PM -0700, T.J. Mercier wrote: > > Hmm... so, usually, the problems we see are resources that are persistent > > across different instances of the same application as they may want to share > > large chunks of memory like on-memory cache. I get that machines get > > different dynamic jobs but unrelated jobs usually don't share huge amount of > > memory at least in our case. The sharing across them comes down to things > > like some common library pages which don't really account for much these > > days. > > > This has also been my experience in terms of bytes of memory that are > incorrectly charged (because they're charged to a zombie), but that is > because memcg doesn't currently track the large shared allocations in > my case (primarily dma-buf). The greater issue I've seen so far is the > number of zombie cgroups that can accumulate over time. But my > understanding is that both of these two problems are currently > significant for Yosry's case. memcg already does reparenting of slab pages to lower the number of dying cgroups and maybe it makes sense to expand that to user memory too. One related thing is that if those reparented pages are written to, that's gonna break IO isolation w/ blk-iocost because iocost currently bypasses IOs from intermediate cgroups to root but we can fix that. Anyways, that's something pretty different from what's proposed here. Reparenting, I think, is a lot less conroversial. Thanks. -- tejun