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 03002C54798 for ; Tue, 27 Feb 2024 06:40:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C2464401ED; Tue, 27 Feb 2024 01:40:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6732B4401E8; Tue, 27 Feb 2024 01:40:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4EA0C4401ED; Tue, 27 Feb 2024 01:40:38 -0500 (EST) 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 3B4824401E8 for ; Tue, 27 Feb 2024 01:40:38 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D9AF4A0F47 for ; Tue, 27 Feb 2024 06:40:37 +0000 (UTC) X-FDA: 81836635314.23.77ED41E Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 46521140007 for ; Tue, 27 Feb 2024 06:40:36 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DmxIq3sm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709016036; a=rsa-sha256; cv=none; b=gIcAIMKH2zMkj0R5N0BtI1qqDfpswnWFfzN3E+sQy4br6U/z4MyT56CwqGfHTTf4PRfrx5 PotAPMW3EYR8P1M9TN64CmpBgz3Rp32x9gceV6ObwL80E/hJjfiCy947Ya9WReP3hvYCDP +gviKXF3qxlXgcBBZk+nvQIkxh8TX0w= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DmxIq3sm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.43 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=1709016036; 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:dkim-signature; bh=NlPT3rui0lg3J1n1cZSVOnotxwJ0BTmY9ECblEb2NZg=; b=pJy1v2PiCWs00nDaahZV5pdnL8vmJNauUT3fBvG1aFbSvgVbF7aPBtq5b55PqnAe3rr0uX le1PSgB9sHn/lrTUu/1MYmiKKXSDRVQ/grew9hULkd9Xk8gJPSGWfUVneZO0ZHxC45YyD0 f8prtVCVzXc44suVpn9c0Mm7dtQq+VM= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-7da9bec3038so657184241.0 for ; Mon, 26 Feb 2024 22:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709016035; x=1709620835; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NlPT3rui0lg3J1n1cZSVOnotxwJ0BTmY9ECblEb2NZg=; b=DmxIq3smtJ3nKSW9uoh9tqEN0d6IzxhRuDGSNxnKB4eOb4S5d3RI1k011uhZK1831w EUqYTbwOsFnS1AsLt40DA1tUZN6fDGse7OPznX4RhxMWbQF82tGZT7jDTxbqavsYgqLB kiS3lSkzNFXgjbfMRbvoX51GC5MY7G3DP0kBKihovIJ/AUIkb8x2wiQESdl5uY2jXndh ml76QHANeQ8bkJqarlU6bX/UHUWqXc/b2D0ujolw5hBtdusDrDWf+fcVKcck/L8Enq83 tGVT7S9MUvYXLbJtJQADZZyvlEbkaOS33bk27abVzW5vFX06ObNNsHB0g5YOOC4v1Ctz G7PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709016035; x=1709620835; 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=NlPT3rui0lg3J1n1cZSVOnotxwJ0BTmY9ECblEb2NZg=; b=X/qfhleWsiZH7HY9cAMNh1bMX/s22s9vhnXUw5C7Q/rNgYYVaFtRDSn/E1XgpAiUlQ X8aNLehuxGCq+p2Or9ObNlppwMZoW4nCIiD6nK/a0JHt6e0grATVYd2+seMvb0H8q3zZ DOwC+AlntpvLbSFuq7FGmbcrIbCNRP6iU3ZKEQQ87deyjUtsSTFkIzQd0D4knppXw1fF E65ucnNeYNAqWs46X8VtZa5K6AdIiAa2nm4eOsFe2zZ35A6PsEH4Myv9rqUoiUw1N5+W uNKXEDWObciDVDMiFshAoINNx4prLz3sVx8K4LRDkZ7F8RB18FGeTk5YgXcHNWXvGx3z DBOw== X-Forwarded-Encrypted: i=1; AJvYcCUb6+qeXn2ebp3cZu6LmCBNnwvjzLgx3nWjj8krNtuSO5hR0ZjF9lTHlanLARIoyegJdXsMwkkgAJndQFOY1eM1lQw= X-Gm-Message-State: AOJu0Yzasq8dRNdiXnyL/sMalaOAkaX7SWXJTbr+2qQc7jhmLVHEX2dG Yl5EdNhD6DFZhHbrmk4NK2I0DPPhZlTLaNbJeFd9t+DgafsMHYWSdWCQv81bdFdJgHQRvVPBQJ6 HoiAmwJNrj+ZVEs6cIWCYOHVICRY= X-Google-Smtp-Source: AGHT+IGNmasMUiU8u0R9GrqNZbHg+Jkwg695WNU+dfnKUWYK3yfWjShC+JRtoU9FT1VLYAZubDqgpeqmYvD6cxFIJq8= X-Received: by 2002:a05:6102:a4d:b0:471:fb75:b92b with SMTP id i13-20020a0561020a4d00b00471fb75b92bmr2730752vss.3.1709016035387; Mon, 26 Feb 2024 22:40:35 -0800 (PST) MIME-Version: 1.0 References: <20240226083714.26187-1-ioworker0@gmail.com> <9bcf5141-7376-441e-bbe3-779956ef28b9@redhat.com> <318be511-06de-423e-8216-af869f27f849@arm.com> <19758162-be5f-4dc4-b316-77b0115d12ce@intel.com> <3c56d7b8-b76d-4210-b431-ee6431775ba7@intel.com> In-Reply-To: <3c56d7b8-b76d-4210-b431-ee6431775ba7@intel.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 27 Feb 2024 19:40:23 +1300 Message-ID: Subject: Re: [PATCH 1/1] mm/madvise: enhance lazyfreeing with mTHP in madvise_free To: Yin Fengwei Cc: Ryan Roberts , Lance Yang , David Hildenbrand , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, minchan@kernel.org, peterx@redhat.com, shy828301@gmail.com, songmuchun@bytedance.com, wangkefeng.wang@huawei.com, zokeefe@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 46521140007 X-Stat-Signature: 1cd359wgd5kj1kjckmqtkdoizcg7f55s X-HE-Tag: 1709016036-950578 X-HE-Meta: U2FsdGVkX1+eizs7CwTtkP0ayrrkqfAhq+cQdrJfS4AkLZdOfZZORVx3kWkJMIpb4Y5suN++fFm7/qS+SMTYStldeTEY1XwVLRy3xYAS56P58z5+0fQiKPMwJhy7bTP5RXfLkBnTj3jGEXbEUT1vJUvKs/K/lD+RmuFVGTiSZNONuNimFJoy3fbj57gwyo3FhJnK5fyASEzJNxBxDZeVxxedKcP86OtmmpSu3L42KXWlfhf179eshHt3st08wbpobm+Fym1nc/gKLPe973GKRcG5oXUphcvvwdIcdW4Nhl292OkW0kL+HMxpcVbsfXoeSezG3qmfBUZlbKfn+is5PSE9HBdwH2AOg2p9YoAR5IGFCwzXwRx/K/Hz3rqHRJAQRnwcUWdUtTDzGoRL/Jmfbv864UVcV3VuHzgnHIZ1vCghnDt4hGyP1wWCCu7WFC2wKsiBKtryhDTqTArTrNTC9tifjhKPSMRHdVX3ybuV4kaWR2kIJGbKKblQ2YCTj15yb8CnwTSTPxTVBBohpp4rSwl72wqBLm7b/EOR2wCgcIlv7N1N7IDMWU/8I5wV+4x85xeygQd2xBw4JvtWFnECk8xph+sO6gXxT5eRQjEBf7G/vL3QbfuwLpe0QYEexNHDbW4dkhS0ImTepH86VFX1CKC4dTRmucrVb5VcPf3pRYNncSlMof1XRxw+3qkTJLVQvjWDS+K4LQZbHAmGTulfJpL4G9DRPXvda1epmksUx3A6+kmuFXXHrvZ6co0mGny7G6YK2Wjt6X1noRfSWOmEize8FIv6fV8GfXLwn+afZIcUhjHEAxp3VrfKLfAgCHEEfwNNvnnR6/nu6l6qTLvx5ec3kVcYQon/XIDCCz61FkJu/pQPVdxEE1u0xmT4TTrbVDxC3PGtSiBnxuPMtNpMAShLTgNrRUEDReyFdKut88HcukJeMB4InTfGqEMpAxDavW9woZ2p8hzjI0I0YYK kP5mbj9a nuX2qNcIUV0yuTTRG0Ha2+mJt6eRnal/H1seN7qzt+gmJqAI0ZD/YIMVA2q1GrJ7+1dze/hkUdDlQ0K7OsCWxeRsBSA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000097, 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 Tue, Feb 27, 2024 at 7:14=E2=80=AFPM Yin Fengwei = wrote: > > > > On 2/27/24 10:17, Barry Song wrote: > >> Like if we hit folio which is partially mapped to the range, don't spl= it it but > >> just unmap the mapping part from the range. Let page reclaim decide wh= ether > >> split the large folio or not (If it's not mapped to any other range,it= will be > >> freed as whole large folio. If part of it still mapped to other range,= page reclaim > >> can decide whether to split it or ignore it for current reclaim cycle)= . > > Yes, we can. but we still have to play the ptes check game to avoid add= ing > > folios multiple times to reclaim the list. > > > > I don't see too much difference between splitting in madvise and splitt= ing > > in vmscan. as our real purpose is avoiding splitting entirely mapped > > large folios. for partial mapped large folios, if we split in madvise, = then > > we don't need to play the game of skipping folios while iterating PTEs. > > if we don't split in madvise, we have to make sure the large folio is o= nly > > added in reclaimed list one time by checking if PTEs belong to the > > previous added folio. > > If the partial mapped large folio is unmapped from the range, the related= PTE > become none. How could the folio be added to reclaimed list multiple time= s? in case we have 16 PTEs in a large folio. PTE0 present PTE1 present PTE2 present PTE3 none PTE4 present PTE5 none PTE6 present .... the current code is scanning PTE one by one. while scanning PTE0, we have added the folio. then PTE1, PTE2, PTE4, PTE6..= . there are all kinds of possibilities for unmapping. so what we can do is recording we have added the folio while scanning PTE0, then skipping this folios for all other PTEs. otherwise, we can split it while scanning PTE0, then we will meet different folios afterwards. > > > Regards > Yin, Fengwei Thanks Barry