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 00C84C3271E for ; Mon, 8 Jul 2024 10:05:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28DD56B0088; Mon, 8 Jul 2024 06:05:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 23E466B008C; Mon, 8 Jul 2024 06:05:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 106386B0092; Mon, 8 Jul 2024 06:05:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E6DB36B0088 for ; Mon, 8 Jul 2024 06:05:52 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 809B081298 for ; Mon, 8 Jul 2024 10:05:52 +0000 (UTC) X-FDA: 82316154144.27.155311D Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) by imf04.hostedemail.com (Postfix) with ESMTP id BA0CC40017 for ; Mon, 8 Jul 2024 10:05:49 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720433127; a=rsa-sha256; cv=none; b=Tny6miV1i93z/JMrVE1npyqSJ44yHYEgqyZBlrdFQd4X10M1FNGGS0ouzPn+8N09mldpNj QdjNkpYudt38n9+8qOjooWPu0cvJf8Z/RbKUQHnn9LImHanh0MsQnkN0QVd8lrV4rdb5/n pFuu/puqVeCb+aBCM7QvP8aVzlW4q3k= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none); spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720433127; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/tsYyibVEXL+6UmILt7GnYiNyfPwNj+z3ZkernFD+Ag=; b=HPTUWdZenFmjdJVmmuL1sqefDgtXxWnYSZHdTqwezbYrqRGlYg2HO/7SmCkkTSmrEFvCwM AhhrmrC3FNYBAiz1Fdr6Vp8lr5XIxTzTOD2uDCoa3SjwGbdUZIA0CmAuvVhXeewvSf4UzH gpbICSHbKpcRSyc1eCJBEAH5nUGHypA= Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-80d61a602f2so1079189241.2 for ; Mon, 08 Jul 2024 03:05:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720433149; x=1721037949; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/tsYyibVEXL+6UmILt7GnYiNyfPwNj+z3ZkernFD+Ag=; b=nSMVr+NjSWbozLMYVuA913wGWxgREJc21WjXuuyXJaKdsIlgwCld79vxDlZyuDhmNz Dg9ATki6sPlzaHC5vp+9Oz9s6kldpi2PoaI/72KLNubpdk0rfanJx6Y/kGl3NowGAe2E JAWHnYK6ehUQogCp7w4n/uVcgvdYIUT3Eg9vgQejwf8t3Y51fhNgWV+zl/k+bbQ2mU5d hN6mbNeMMGvJqavF7BE3UkIH3UtcsnfSeNUJ17KywLU4ACR87DPBOIqm3vdxZJ4pxQIP +ApO5EwEYZRJfqyIqkMwLs/vYqCAsvGW5gH83pgA6DmAoWZvKPE6exgnz1Z2BAM6hPfA I+ug== X-Forwarded-Encrypted: i=1; AJvYcCV26SqF3YOrjq5hZ70VY23ToO4f/jKqsQjplO3nGFr3VOcHspCJz9xbEe/bpKv2u9FAA9HpDll7sUPSqyl5uZA8c94= X-Gm-Message-State: AOJu0YwfyAyQNoVvp8KbpENZ54KgLNInngwR5VmXCC2sjb//AL8TKpl7 zHXX3o5JbhJXHT+dIZDBxvulQOLj6JzQnjgy1OxrejajBd+c8AMWxrxxNQnPyqbmZ8mIxQyuSUh kgjw7qxnM2qiAr5iR4YSA0jIFWQo= X-Google-Smtp-Source: AGHT+IFSPah4hfiBN6PfhxDs/lAMd6pYf3ppUrht3vHNaTQSMPvMhayjumxla0Vg9p9RnsmuJ+1WSVPyQimrmvMSm/E= X-Received: by 2002:a67:e292:0:b0:48f:4416:dd59 with SMTP id ada2fe7eead31-48fee7ed7famr12349014137.33.1720433148742; Mon, 08 Jul 2024 03:05:48 -0700 (PDT) MIME-Version: 1.0 References: <20240708090413.888-1-justinjiang@vivo.com> <611dd616-a626-4968-b88a-4db82dccfb90@redhat.com> In-Reply-To: <611dd616-a626-4968-b88a-4db82dccfb90@redhat.com> From: Barry Song Date: Mon, 8 Jul 2024 22:05:37 +1200 Message-ID: Subject: Re: [PATCH v5] mm: shrink skip folio mapped by an exiting process To: David Hildenbrand Cc: Zhiguo Jiang , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, opensource.kernel@vivo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BA0CC40017 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 48rscqx5814m4qin789xncy575noucxb X-HE-Tag: 1720433149-385201 X-HE-Meta: U2FsdGVkX181QiBtr6RlpDrbPVhKBrO959ZoiMwV1IkL/+r3AZHLeLVBCGRbwhdQ+g4ElxcqGf1yhdUzkpw3a23ghdRNFmpIlyL6PID8kf0cQPvoRi+GViSavGC7fKEpHPAUHWytCL0Xa12fbe77krkoeqL+SL8ZCEguTXxsEqFMS/lFVSTiZni9rolvEX7GMuyOWmlCJBQEL0ybjpnlqu2OFfwSug6cAdY+CCvgSEEwscmh8tczD3yGgECT0/6jEpWmgfwm6+Ii+6gmZqFZ0aSAjysJGQ0tfEbhnctcw5/qBx/swuCqj9u1axRF0E2T/OXQNv0n8OzKlhj/ByDg11phC0XAIsNUhaiNawh1ceIuVXegzG+lbFhLNaaBa1iZYv7DZnw4KkQ6XWVJm4XeKjhw3yIYEg8FBkPZGkeJeyboW2MxNb2/c3ApzOlzn54Bbiq6YRfkBUXxYVvol+JIYBFKaCq1lwzCmeJZ7oUmaX0/D07r2OlGBYTDns/qR0PDaFoqKBdLHLGnZ6BeRMecw7UOYaBUldR9InFqxuO5R01TuvMD2aoBG6WmyXFEbIviDFM7/CTBNXhS2omH6I1OVRF8uLwG+9Wj1RM+W+20z1Fr/FBHdPQSdB+wjaqYEhNaJtCtAm2MGJRRXr2gFSsJ+bb1i+BpMKBxjFQH1VRioQQ6QCezZI9t7URlSaqD8NAT8y+504t6ZSr6Fey8FWE9klzUZYeB0IOqv6AJLYD2kQ1ETN0BS4NCsh57M5Cyc1UXjdAx3Abr6bK7jmY3zMq3hvoE8Ee8ImpTqooqpEu9KO49k6zprdNlN0ZMoSVUrN06J70O/XAINjIVXjdaPXhdsDXU7Si3TUfEaTpiUR59+dSRUWATaizDjDOCEje3eEqAzO+hfeVwuNCGkQeQW+RE7X/1m4YbIVzft0nspmMWMh1ryNXAg1i0YYEGDn9gHSanhqcUGwOBg5wwKkIwjM1 4VjXR2d/ oMbEPBv6MnQAr8RLjMbgRx2SkDkozAPBxVzxW9xHCYaFU7TsW+ODTgFJJkdheSSAkWB6MHXP2HSZd/HVkraRv4LbE89SNkAf4LRUhHV79bhPlGntTEJsDAAP2r/nu1HmI+67lq+l9MCEQRHfgES0Zr2+8h3ouhUhvhg/19ae6t3B8uzNvdheDvauin7cGqse7RZLd7JCycbI9vffPPeYizNzu4Tb8iku/Jr1xGjFhuWlHQb5LZAnz+Dv1fjk3fR9WmxiMt/pH4cIRM+2gvDluFEB8yoik90BdMObD2dk9Gm+RqFIg5prFYmr2nMB57+YpEXIVRTrNCQM3rIXWKprJaRGzH3BVBHTdRjnSFKuYl3z30+k= 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: List-Subscribe: List-Unsubscribe: On Mon, Jul 8, 2024 at 9:49=E2=80=AFPM David Hildenbrand = wrote: > > On 08.07.24 11:46, Barry Song wrote: > > On Mon, Jul 8, 2024 at 9:36=E2=80=AFPM David Hildenbrand wrote: > >> > >> On 08.07.24 11:04, Zhiguo Jiang wrote: > >>> The releasing process of the non-shared anonymous folio mapped solely= by > >>> an exiting process may go through two flows: 1) the anonymous folio i= s > >>> firstly is swaped-out into swapspace and transformed into a swp_entry > >>> in shrink_folio_list; 2) then the swp_entry is released in the proces= s > >>> exiting flow. This will increase the cpu load of releasing a non-shar= ed > >>> anonymous folio mapped solely by an exiting process, because the foli= o > >>> go through swap-out and the releasing the swapspace and swp_entry. > >>> > >>> When system is low memory, it is more likely to occur, because more > >>> backend applidatuions will be killed. > >>> > >>> The modification is that shrink skips the non-shared anonymous folio > >>> solely mapped by an exting process and the folio is only released > >>> directly in the process exiting flow, which will save swap-out time > >>> and alleviate the load of the process exiting. > >>> > >>> Signed-off-by: Zhiguo Jiang > >>> --- > >>> > >>> Change log: > >>> v4->v5: > >>> 1.Modify to skip non-shared anonymous folio only. > >>> 2.Update comments for pra->referenced =3D -1. > >>> v3->v4: > >>> 1.Modify that the unshared folios mapped only in exiting task are ski= p. > >>> v2->v3: > >>> Nothing. > >>> v1->v2: > >>> 1.The VM_EXITING added in v1 patch is removed, because it will fail > >>> to compile in 32-bit system. > >>> > >>> mm/rmap.c | 13 +++++++++++++ > >>> mm/vmscan.c | 7 ++++++- > >>> 2 files changed, 19 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/mm/rmap.c b/mm/rmap.c > >>> index 26806b49a86f..5b5281d71dbb > >>> --- a/mm/rmap.c > >>> +++ b/mm/rmap.c > >>> @@ -843,6 +843,19 @@ static bool folio_referenced_one(struct folio *f= olio, > >>> int referenced =3D 0; > >>> unsigned long start =3D address, ptes =3D 0; > >>> > >>> + /* > >>> + * Skip the non-shared anonymous folio mapped solely by > >>> + * the single exiting process, and release it directly > >>> + * in the process exiting. > >>> + */ > >>> + if ((!atomic_read(&vma->vm_mm->mm_users) || > >>> + test_bit(MMF_OOM_SKIP, &vma->vm_mm->flags)) && > >>> + folio_test_anon(folio) && folio_test_swapbacked(folio) = && > >>> + !folio_likely_mapped_shared(folio)) { > >> > >> I'm currently working on moving all folio_likely_mapped_shared() under > >> the PTL, where we are then sure that the folio is actually mapped by > >> this process (e.g., no concurrent unmapping poisslbe). > >> > >> Can we do the same here directly? > > > > Implementing this is challenging because page_vma_mapped_walk() is > > responsible for > > traversing the page table to acquire and release the PTL. This becomes > > particularly > > complex with mTHP, as we may need to interrupt the page_vma_mapped_walk > > loop at the first PTE. > > Why can't we perform the check under the PTL and bail out? I'm missing > something important. You are right. we might use page_vma_mapped_walk_done() to bail out. > > -- > Cheers, > > David / dhildenb >