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 7B708C3DA4A for ; Sat, 3 Aug 2024 19:08:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A36D46B0096; Sat, 3 Aug 2024 15:08:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E6CC6B0098; Sat, 3 Aug 2024 15:08:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AD6B6B0099; Sat, 3 Aug 2024 15:08:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6CF016B0096 for ; Sat, 3 Aug 2024 15:08:26 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D505C81468 for ; Sat, 3 Aug 2024 19:08:25 +0000 (UTC) X-FDA: 82411870170.19.0CC4CE6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id C91E8A000B for ; Sat, 3 Aug 2024 19:08:23 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=VLNK5uoZ; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722712074; a=rsa-sha256; cv=none; b=y8pCJ1PaIFRm5XrXOe357syB6QgHPOdGMtpWHad0P5zFDY5yD0w7TTqfNGstIXXQlh5PqU m5Lumi2FqiWT8bvAKydGE+TByOgX1sSsWWgPCh+ejslUt1LXb+b/OfwPViPWcLWGRdypz7 PswyGbnzNo4i1z+GdhUCbClRICSS2BY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=VLNK5uoZ; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722712074; 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=CyMvEBiz23W8rcnTjFMJz31yqv455ZscFrbIJ5VzvVY=; b=b8YqTVIXUz0uPbhL9rEw8dZ5hT7caGW4LmkbKNzWD5/zcmbk0GbUhN7YitzPAEX7HuOGHb 0UyIi+a8q9aDv12obT6+oyDF3YsYRRPezufpSSgmtgKfaeDV2T2rPnFwk4yhDrfgrA5rBE FszAMuCuVUCc48FTzlNhfn8oXSf2Rh4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9268A60277; Sat, 3 Aug 2024 19:08:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65F02C116B1; Sat, 3 Aug 2024 19:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1722712102; bh=M4MvruE1F4Gz3Tgefob3wbbY6lpPmTqXqxP8x8F1p9E=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=VLNK5uoZn/RSkGEnGD++mhKTHZ6Hn/ntuYHrFSBubyI0M7T699Z9WWetd6WcmqUVy Txw1ZsxOnneKRX4TgtVilL8a78UlzSToOpNBdg4/lLRCBaDIroV5mcVkdZ6Uou79Tk vhbHtNTX/8epGxMSR+/72D/0uAj0AB56gLpOb8JQ= Date: Sat, 3 Aug 2024 12:08:19 -0700 From: Andrew Morton To: Barry Song <21cnbao@gmail.com> Cc: linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, mhocko@suse.com, minchan@kernel.org, nphamcs@gmail.com, ryan.roberts@arm.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, hch@infradead.org, Chuanhua Han Subject: Re: [PATCH v6 2/2] mm: support large folios swap-in for zRAM-like devices Message-Id: <20240803120819.b2f539115ad3cec84de967bf@linux-foundation.org> In-Reply-To: <20240802122031.117548-3-21cnbao@gmail.com> References: <20240726094618.401593-1-21cnbao@gmail.com> <20240802122031.117548-1-21cnbao@gmail.com> <20240802122031.117548-3-21cnbao@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: 6aajw49k7ij56hmaw7enf7pmo45e8meo X-Rspamd-Queue-Id: C91E8A000B X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722712103-860185 X-HE-Meta: U2FsdGVkX18l3kC8S+5H3Uyvq9+akc5cbw5bG2OMm9EU1nT8zeR0QcOULoUwTaYtjScMHNSot6C050ea1GSk5uKErO/XYduKUGC8/Aciz9ISrpDcRAjd1+Ir7yUtxnJka2+kvk6SCJ2B0dJk6pfUxriL7CsaNMBkMiILVoPfN/fhTPK3Zw/ii0PzBgUDE2bsDxVZr5GDaTF62xHpQeMTxRn87jEl3QpNDvxKL1xpubZ+SB4EFQREeWrOnwizOLcUKzogweWl/8yaTC6LZvbRstKmeienc4RdfzxdujXQrKCj6GzJUef78Nx4GCu1j5KY55fRCVHgX972cl7Ke6grWlR54BylqaUMFbXFlJzFR2zlayEYYPYWGCrrOzrAZFczI11Ylj10DmcTMpy1hHdcqCdxQ7Z8R8xFh22L/Zfupt3Y9R4St5ILLT+HV7Ly1BXK8P4VzVUOzDY7sPtVsIY09XCup2MOt0K0gjFcpHBKIjM0WgcnDepTjLfrBjCU7iNtbRrbiMYQ3Lx27PMnho4BXDsl9qPe52MA7tZVKpOaq2LK8gY+pRjXu+lbl+Gvum+xrfvV1W4llDVOngLF3UWgOW3YKrUq+T3y3OwBTj7wKrznqOHlW2NKL29TkbFmScQlOfKvYrtNcVTyYOLixOILWlm3uKr7h/v88vKkzrAZNdrbWpcJ8Ce8p58ghmY1824TlQUmyFkgwMQf+WD5rcEs4XqPIXZwkv8axWveiw6zlBBW09hfdI+u8DgXHXQC+k3qMRCeYfzq1kwLYQiADe+wpZ4LMS7DPBRxt0Rtq1ytLdmlMNcNyl8AW25qnX8sygrwg/qYW0aCVfY/d3N1EwLEw2LNqyR/dLtl7s1NqaZTjtUu6reEOA6Rf7yq/uIt/RlWHRKtG1T1Z1cLcg+BUACEGac+Ls02kj4O8QpX70+w8FSpIzBCikWCsAEv5L4Nrs/n6AiWQu3fK+wNVU1VX9z qDWOsXFT BH3JKRtihOGLmiBv8z9ixbFzbwKiX+TCkHev18pmBBGcHytD4qs0p8oN3FEGJvNVXoAh5Yi6pPyQnD6lugs0DCi8NK09fl9PwbuFdXs9QpPAJVU4pEQSCgpDwEO14F86O5QD0XZu0H0MQRnEYjuj2vx/BGpYWaY7aQu2vec5edRvU6xRbyzR7rLhh7oyxHtbccNuDz5aeLr4H5OgHXUDYK5ZmxB+A3/Ulw71Q7e5kGAB7ipGJxU6O6Aqhe3WCAwxp74MRRAeMjidaUSHguyjtQdxtEerK7Npt6ExZUm18JcxwazRxRQ27v+/wJnQrtapgU2+m9K9O1nk87L6gZB9Dm18EXpGMtJB0phz+9rBEDEP3m8yj9fi3Sq3qtlIe1hflEmZb/NNSMBDvSAgENhf1nu0gJW2vpLOKo7vOe1dTfTXPC5qn5c9YNozoAlB4tK0OK+oCsN2x1qrSUBG1nloOAInM9h/1/rIRvqb30YRxf5XHFXE+ebk6bDuO/6H2Hzw9ihw5ymhgViF/xMIVZCRwjBpohk4fmOBw+D1BZiUIsqxfTVVP6nCnsWUqDCRTdhbLlkyXOeZ3atQW4IKyk7iEG0XCUI6AkTDxo9PGwaaZ4p5HPfvZiwe13wSIhJ4KtcUPq/q7ZiMbigAbFOYkS+DCX7A4Th8fi9PZhKa0L7tV2oQQh7HcnNrkmMsaeTR8hMJ09yANtYFoxyNL+ATs6Qz3TC9aKNb0JTl1FaGtArqeoy5Cnbpy2DiFtRIFDKgcJd8g1VOT3IxHbJDwicbmgqFeWfONuMnnWMupkQTbhTarI0VzEHdQaTQt2YhdRQYTaKDcJEVoU1nyQcDIm+Rt7+4h+EiBmxJaKutoFnb/yFRyvg/hFpnE5B3zgqwAtA== 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 Sat, 3 Aug 2024 00:20:31 +1200 Barry Song <21cnbao@gmail.com> wrote: > From: Chuanhua Han > > Currently, we have mTHP features, but unfortunately, without support for large > folio swap-ins, once these large folios are swapped out, they are lost because > mTHP swap is a one-way process. The lack of mTHP swap-in functionality prevents > mTHP from being used on devices like Android that heavily rely on swap. > > This patch introduces mTHP swap-in support. It starts from sync devices such > as zRAM. This is probably the simplest and most common use case, benefiting > billions of Android phones and similar devices with minimal implementation > cost. In this straightforward scenario, large folios are always exclusive, > eliminating the need to handle complex rmap and swapcache issues. > > It offers several benefits: > 1. Enables bidirectional mTHP swapping, allowing retrieval of mTHP after > swap-out and swap-in. Large folios in the buddy system are also > preserved as much as possible, rather than being fragmented due > to swap-in. > > 2. Eliminates fragmentation in swap slots and supports successful > THP_SWPOUT. > > w/o this patch (Refer to the data from Chris's and Kairui's latest > swap allocator optimization while running ./thp_swap_allocator_test > w/o "-a" option [1]): > > ... > > +static struct folio *alloc_swap_folio(struct vm_fault *vmf) > +{ > + struct vm_area_struct *vma = vmf->vma; > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE > > ... > > +#endif > + return vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vmf->address, false); > +} Generates an unused-variable warning with allnoconfig. Because vma_alloc_folio_noprof() was implemented as a macro instead of an inlined C function. Why do we keep doing this. Please check: From: Andrew Morton Subject: mm-support-large-folios-swap-in-for-zram-like-devices-fix Date: Sat Aug 3 11:59:00 AM PDT 2024 fix unused var warning mm/memory.c: In function 'alloc_swap_folio': mm/memory.c:4062:32: warning: unused variable 'vma' [-Wunused-variable] 4062 | struct vm_area_struct *vma = vmf->vma; | ^~~ Cc: Baolin Wang Cc: Barry Song Cc: Chris Li Cc: Christoph Hellwig Cc: Chuanhua Han Cc: David Hildenbrand Cc: Gao Xiang Cc: "Huang, Ying" Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kairui Song Cc: Kalesh Singh Cc: Matthew Wilcox Cc: Michal Hocko Cc: Minchan Kim Cc: Nhat Pham Cc: Ryan Roberts Cc: Sergey Senozhatsky Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: Yang Shi Cc: Yosry Ahmed Signed-off-by: Andrew Morton --- mm/memory.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/mm/memory.c~mm-support-large-folios-swap-in-for-zram-like-devices-fix +++ a/mm/memory.c @@ -4059,8 +4059,8 @@ static inline bool can_swapin_thp(struct static struct folio *alloc_swap_folio(struct vm_fault *vmf) { - struct vm_area_struct *vma = vmf->vma; #ifdef CONFIG_TRANSPARENT_HUGEPAGE + struct vm_area_struct *vma = vmf->vma; unsigned long orders; struct folio *folio; unsigned long addr; @@ -4128,7 +4128,8 @@ static struct folio *alloc_swap_folio(st fallback: #endif - return vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vma, vmf->address, false); + return vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0, vmf->vma, + vmf->address, false); } _