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 80BD3C5475B for ; Wed, 28 Feb 2024 23:18:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA6096B009C; Wed, 28 Feb 2024 18:18:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E55666B009D; Wed, 28 Feb 2024 18:18:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1CC96B009E; Wed, 28 Feb 2024 18:18:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C2BC56B009C for ; Wed, 28 Feb 2024 18:18:30 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6D45412080E for ; Wed, 28 Feb 2024 23:18:30 +0000 (UTC) X-FDA: 81842778780.22.DF60EDE Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by imf20.hostedemail.com (Postfix) with ESMTP id B73111C000B for ; Wed, 28 Feb 2024 23:18:28 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=E9nzRkCQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 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=1709162308; 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=QgfsSS2pCIePMWBGptAQ7Z9dl3gs0fMNB2rNkVErCLs=; b=tuy1m4QY8l21hgKDuiX96JuiVkm2z9WusYQV+/uFQhqKZF+OgmWEuUof+xdm8CQ6TAd/Gx +kdkNjU7DKROsDRNQDkSKPM2QEsDklSp8XY/37n3/9czsm07/9YoOHvVzkzSwkXtLpCZIM If+dxw9CAZQ/VsT1lwqpbzRjt1gYoM0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=E9nzRkCQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709162308; a=rsa-sha256; cv=none; b=X0YAkoaWV+ipQ52LgDyD2uVtCcEMlaYGJZiA1ahkVb5VPpcSmjERFA9wNliuibFV++k9DV bCZJIwIkFC1c6YZXMf3VLcwG0XdemMhsYw4a3zyEmS4F8JOegNbCSAxevOKT7JOp3fRd1i JNPihcCOCNqaLIe7dGVtQakRbZOS2bg= Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-4d33b077ec9so69553e0c.0 for ; Wed, 28 Feb 2024 15:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709162308; x=1709767108; 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=QgfsSS2pCIePMWBGptAQ7Z9dl3gs0fMNB2rNkVErCLs=; b=E9nzRkCQcme/673hR2iW35qgm8q7YELloIKhCTWKLZu9nS2laX+KLI0BJIfv57cBa1 5vuNswz5c6SvJik9HMLkClFwJA8hrIg1+8bfxSAkRbE8/7gJIF6QaF+iMLpCmBkd5DMr tI8HgUHUWZnSt9Kr+E4OLpMQguB8Y6Pfrnhwb9rZt/mM2kPv4sLIADyWYX1mRubHObgE 7L7R3dNiHKyn7uec1+dC4ssoV9QqCD8RqEfbH0SMYpvGLZe07lWQtTcZ4RFYhUmnhjzP UMV64The8oCWxsavWaLCC89YXhCzTDmDV+QdpXGQZRY1iRtmtutIDCuGPhL4DO/S4qFW lAIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709162308; x=1709767108; 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=QgfsSS2pCIePMWBGptAQ7Z9dl3gs0fMNB2rNkVErCLs=; b=E/RTsAYWVmct1exZDyn1nWixg0kiFZ8QIQypYG7YwRlZkHDRsNeHMKSfO8KuCPqNaY aITjm0CZLOo3cwCNo4O0VXaQRAKMpD9EpIpxubf3QHFJtanXbMFgrtrwxgmDGpMIuzRk H5SbqHk9pt0Sd/FbQwqp6HCUZLlBZzFN+z9rwncP7apItrKSAprxpbYR4TaVMm1HXyhE q5FDqI/uDWSW7g6Iwa7IXNm/q0RF5HHvgXLmYRZt6qyxyIQ0PqbDNGa9ImgbnOyl5Pul WIS/yKckXUKs/GzgYzwoCQIVO6CvBsiNOQ8hSH11A2ReMHUB+Jkw4NqeZx+AgGV3amUp 9RBQ== X-Forwarded-Encrypted: i=1; AJvYcCWbEQSQXkCWpX3DAJ213oqDmQAVb1gtqAATvhqUutqM8Nex3QsNh6g9SWvw067afNRdo7KXtRIbG705aaVmztB9UUs= X-Gm-Message-State: AOJu0YxnFtdYBVbyotSV80wT2JHW3yYLplF8Jv2dlT5nBPdnaYTlykEt MbM4jA83GLbN0qKd6KohxoJ2k5YMdD/27kpQx2cL2mjVjdoM5sVO9H9n7zr7y+L3UwwFZn3R/nT CIoEgxHB4TCP6r66bRAKt8dXWw4I= X-Google-Smtp-Source: AGHT+IECs8iMY1YnYPJpryVfFh8VT25O/SfR3YnlQmuu+oyBiX4Kuyt6DsSjCaMbB4d1WSsWdF//N3m6ojejD1lNTxA= X-Received: by 2002:a1f:e4c4:0:b0:4cb:56c5:580e with SMTP id b187-20020a1fe4c4000000b004cb56c5580emr345301vkh.11.1709162307693; Wed, 28 Feb 2024 15:18:27 -0800 (PST) MIME-Version: 1.0 References: <20231025144546.577640-5-ryan.roberts@arm.com> <20240222070544.133673-1-21cnbao@gmail.com> <1a9fcdcd-c0dd-46dd-9c03-265a6988eeb2@redhat.com> <1d9b85ce-63d1-43b4-a4ad-b9c1d89f952b@redhat.com> In-Reply-To: <1d9b85ce-63d1-43b4-a4ad-b9c1d89f952b@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 29 Feb 2024 12:18:16 +1300 Message-ID: Subject: Re: [PATCH v3 4/4] mm: swap: Swap-out small-sized THP without splitting To: David Hildenbrand Cc: Ryan Roberts , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, shy828301@gmail.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com, chrisl@kernel.org, surenb@google.com, hanchuanhua@oppo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B73111C000B X-Stat-Signature: ugyz65qusf6a8knmy8jz6skdxdrmqx38 X-HE-Tag: 1709162308-740267 X-HE-Meta: U2FsdGVkX1/rpUTnoiGnY/JqPHMgkwuYeu6fSKMel0Aj/UbDpmbtFTQgV0BriOULNthr9QxPVTWvP0JRkZvNRdx0jq2gAERmKJWd/0b5kmEB23MZBhgsEpFBcf7anf0gUlPX8wZRgSwVqVbfx5/c+WMmYLV//4VJf2ikAPMJtkE+xTtC7aorhkN9Z++VSaijC26iTgoyTFBhpLOSX8ruzfEZ8c+0Cxkt6Sq8sa/r+PxIHKIofLyFjsPal2zNtejlDrV9hbDx4s+OalEd1WOtenoLTA4FxEaDzDu5ApBdiI4mfUaBmTji3vGnsZt9imM9TYXOrHP9c6aiYJg/QAepxqXnnvnHc3qMY/rJW4hdIJH3O3+pcxN30eGiKQa6LiwYkY5pPGLUljSDT1bDStsV5DMllE+29eOjKWOsJxJTKQtCOcY/ALh0EEIT+vrTcrpj8KJXSLC8wk4l/O1cKb7LusgnCsMwSaEP1AOWkPHZC8a5PtHQo4sI8Dd1/alsp8gLU3ZY1HK8prlr678Q+aQ5CqoH//MQMHfS1GiHIm3clC3mAuy7WU7qFCiYqeMrZkr78Rd0uYqQXutvhGfAyYKBm/tE7z6oFMS2Ny37G4KmKEwRv8x8r3XJ7dojiuZH1usvUtTw4CatTrouLSGdHm16sniTfp0S9SvOQgGiclhLYD+Gbp/hf+9mIjpcOHzlDqqvdFKA3BOqyz8Sj0evurQ48G8JbXWS9JyimJxJ0M85nDhcktNBt6INgc+C4BCuYzmm08DPTpDz2HhTeWMJ6di475qR7F3GEoBfpJuvWaL3v2TqzeRuRnyik3ETVQl8f2h1IFhaV41kbeLdvUtofbGCo6y0frN/INtm10Ifs7FVYffUQhsPHPJzeX3sv6rHjQ+qdigDZAPOxV4QJd47wJwe+0bVxUlmLuhosWPbnp2Ux0uP6Oc+u83cc/KecO97mxRQMAAgkvvcSRs+1gKQ9VW alT6+f4+ ESgEr9u4QapjK4ZsEYcbVdx0qU91n9AdExkKY X-Bogosity: Ham, tests=bogofilter, spamicity=0.000205, 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 Wed, Feb 28, 2024 at 10:34=E2=80=AFPM David Hildenbrand wrote: > > >>>>> > >>>>> To me, it seems safer to split or do some other similar optimizatio= n if we find a > >>>>> large folio has partial map and unmap. > >>>> > >>>> I'm hoping that we can avoid any new direct users of _nr_pages_mappe= d if > >>>> possible. > >>>> > >>> > >>> Is _nr_pages_mapped < nr_pages a reasonable case to split as we > >>> have known the folio has at least some subpages zapped? > >> > >> I'm not sure we need this - the folio's presence on the split list wil= l tell us > >> everything we need to know I think? > > > > I agree, this is just one question to David, not my proposal. if > > deferred_list is sufficient, > > I prefer we use deferred_list. > > > > I actually don't quite understand why David dislikes _nr_pages_mapped b= eing used > > though I do think _nr_pages_mapped cannot precisely reflect how a > > folio is mapped > > by multi-processes. but _nr_pages_mapped < nr_pages seems be safe to > > tell the folio > > is partially unmapped :-) > > I'm hoping we can get rid of _nr_pages_mapped in some kernel configs in > the future (that's what I am working on). So the less we depend on it > the better. > > With the total mapcount patch I'll revive shortly, _nr_pages_mapped will > only be used inside rmap code. I'm hoping we won't have to introduce > other users that will be harder to get rid of. > > So please, if avoidable, no usage of _nr_pages_mapped outside of core > rmap code. Thanks for clarification on the plan. good to use deferred_list in this swap-out case. > > -- > Cheers, > > David / dhildenb > Thanks Barry