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 2AD4AC4332F for ; Thu, 6 Oct 2022 07:31:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 303966B0071; Thu, 6 Oct 2022 03:31:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B4486B0073; Thu, 6 Oct 2022 03:31:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 154C46B0074; Thu, 6 Oct 2022 03:31:25 -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 F1E8B6B0071 for ; Thu, 6 Oct 2022 03:31:24 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B2F4F1A0634 for ; Thu, 6 Oct 2022 07:31:24 +0000 (UTC) X-FDA: 79989704088.04.40C18C1 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by imf10.hostedemail.com (Postfix) with ESMTP id 574B7C000D for ; Thu, 6 Oct 2022 07:31:23 +0000 (UTC) Received: by mail-wr1-f48.google.com with SMTP id r13so1260155wrj.11 for ; Thu, 06 Oct 2022 00:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=RVWW/BaJYSJb5iFCcmVWgHh8lf5q5nSO5D6+WwfrGO0=; b=mBl1Gv36EpxEHwxD8G7c2u80/IL6+9yVxn+9bsflcmtYODk4l9xKEbagkili2v3OxI XjdikoyYoP1QyAmW0TZErMbO84gMIB6gcm6OYndYagBwSrqg9Gy4hv7im3obX0sBrq3p qG/hjkBWPS6Ku3/fjoIlhVjcF58vx5EDYDbEXQV215CHEO4WTUxZ6janp1qrFyDboI/w OOo7kmv3GN2o97SK1InevEG172WD5n92gOjtHgaSDG0nvTAvYaHKUFk1a40joFB5wq9W 04WeKaJxs/LPaW2NmdgChnXxn6tpuD1tcm9ISfoO9lHunE2GHuEn5rl04s9FhpFGXaMN smIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=RVWW/BaJYSJb5iFCcmVWgHh8lf5q5nSO5D6+WwfrGO0=; b=5DtAxtv1zmYrlVuTwWKnbn3QrpbKhHIS5bXezLjY7d+uTef9EFP6C4qdhIHL6hhffu SORNX3sM+KxDsZJ9Hn4uvAWEf7srexnrRs/Z+0VHD8qDwM0rD+B0gFcz8KWi8trGUb3H Hrw8qCyK7ILRuk8pX4w30kcvkT7H5z9itixcVV6I8mfCXXcOh1Ullxka50KcHRzkT+wF fdbCKf8NErKW9LnBkwQohIsBBglRJUQpLNCpZKXnHbC4Avu/x9eY2PiPxYbHgnDYh3dC ptzNLBbaNx4AORu4qxQhfZUdyBrRsV2XdG3lGo/NKV7EfX2QtoeK6phfp/9kiwuW9yym IJ1Q== X-Gm-Message-State: ACrzQf1qcYDtyS603Km9L64Z7zNAcDQBa2LbX8DL7HI2wIvgZTdBzl0X KbhayaeC/UprGq88X3FeeXis6NfwUjCx4SgUNh+X2w== X-Google-Smtp-Source: AMsMyM4F8plDfzsO4L9/zK32C+FXqkAqa2FGfRbFh1YLiFVJeQ15FU4Yvw6zh5fQyrQBEgCP8iE/zP+zKvziVDYpiCU= X-Received: by 2002:adf:fb05:0:b0:228:6463:b15d with SMTP id c5-20020adffb05000000b002286463b15dmr2091087wrr.534.1665041481940; Thu, 06 Oct 2022 00:31:21 -0700 (PDT) MIME-Version: 1.0 References: <20221005173713.1308832-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 6 Oct 2022 00:30:45 -0700 Message-ID: Subject: Re: [PATCH v2] mm/vmscan: check references from all memcgs for swapbacked memory To: Johannes Weiner Cc: Yu Zhao , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Greg Thelen , David Rientjes , Cgroups , Linux-MM Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665041483; 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=RVWW/BaJYSJb5iFCcmVWgHh8lf5q5nSO5D6+WwfrGO0=; b=sr/WQEZtTM905aAJ0QKC5KdstNsr/K0+SRrpK/Ukd4CkNB8pWG6r75zeTqfhnOb5X3Leuk C3B18aOwsc2UN5LVdtuqcphInU6f6KerU0jkGSTO+hjlNKkpApq20bujptnA4TXpV5uYs6 cRm8L3rcvk8fjMuzNbrFYJJxosDjsP8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mBl1Gv36; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665041483; a=rsa-sha256; cv=none; b=qSABZ1NqW1UUH+B5sl3bMOMk3j6ic2ADdt0oNeqeBgR0V/s93+cx1Vi8X/GLtmjX+h7RwC fuvg6X9c02DAZzvXRrQbLUZKAqioebPgC3CPUASU1ommcy3zFBdwb0gphIG4i0h3HScPi1 +TyKZFIV9T6CP1dXqG3jf7fzXoGsfU8= Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mBl1Gv36; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 574B7C000D X-Rspam-User: X-Stat-Signature: fk9ca69yikz7xodr1i46c5q8fp75i56o X-HE-Tag: 1665041483-871375 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 Wed, Oct 5, 2022 at 9:19 PM Johannes Weiner wrote: > > On Wed, Oct 05, 2022 at 03:13:38PM -0600, Yu Zhao wrote: > > On Wed, Oct 5, 2022 at 3:02 PM Yosry Ahmed wrote: > > > > > > On Wed, Oct 5, 2022 at 1:48 PM Yu Zhao wrote: > > > > > > > > On Wed, Oct 5, 2022 at 11:37 AM Yosry Ahmed wrote: > > > > > > > > > > During page/folio reclaim, we check if a folio is referenced using > > > > > folio_referenced() to avoid reclaiming folios that have been recently > > > > > accessed (hot memory). The rationale is that this memory is likely to be > > > > > accessed soon, and hence reclaiming it will cause a refault. > > > > > > > > > > For memcg reclaim, we currently only check accesses to the folio from > > > > > processes in the subtree of the target memcg. This behavior was > > > > > originally introduced by commit bed7161a519a ("Memory controller: make > > > > > page_referenced() cgroup aware") a long time ago. Back then, refaulted > > > > > pages would get charged to the memcg of the process that was faulting them > > > > > in. It made sense to only consider accesses coming from processes in the > > > > > subtree of target_mem_cgroup. If a page was charged to memcg A but only > > > > > being accessed by a sibling memcg B, we would reclaim it if memcg A is > > > > > is the reclaim target. memcg B can then fault it back in and get charged > > > > > for it appropriately. > > > > > > > > > > Today, this behavior still makes sense for file pages. However, unlike > > > > > file pages, when swapbacked pages are refaulted they are charged to the > > > > > memcg that was originally charged for them during swapping out. Which > > > > > means that if a swapbacked page is charged to memcg A but only used by > > > > > memcg B, and we reclaim it from memcg A, it would simply be faulted back > > > > > in and charged again to memcg A once memcg B accesses it. In that sense, > > > > > accesses from all memcgs matter equally when considering if a swapbacked > > > > > page/folio is a viable reclaim target. > > > > > > > > > > Modify folio_referenced() to always consider accesses from all memcgs if > > > > > the folio is swapbacked. > > > > > > > > It seems to me this change can potentially increase the number of > > > > zombie memcgs. Any risk assessment done on this? > > > > > > Do you mind elaborating the case(s) where this could happen? Is this > > > the cgroup v1 case in mem_cgroup_swapout() where we are reclaiming > > > from a zombie memcg and swapping out would let us move the charge to > > > the parent? > > > > The scenario is quite straightforward: for a page charged to memcg A > > and also actively used by memcg B, if we don't ignore the access from > > memcg B, we won't be able to reclaim it after memcg A is deleted. > > This patch changes the behavior of limit-induced reclaim. There is no > limit reclaim on A after it's been deleted. And parental/global > reclaim has always recognized outside references. Do you mind elaborating on the parental reclaim part? I am looking at the code and it looks like memcg reclaim of a parent (limit-induced or proactive) will only consider references coming from its subtree, even when reclaiming from its dead children. It looks like as long as sc->target_mem_cgroup is set, we ignore outside references (relative to sc->target_mem_cgroup). If that is true, maybe we want to keep ignoring outside references for swap-backed pages if the folio is charged to a dead memcg? My understanding is that in this case we will uncharge the page from the dead memcg and charge the swapped entry to the parent, reducing the number of refs on the dead memcg. Without this check, this patch might prevent the charge from being moved to the parent in this case. WDYT?