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 15BCDC54E66 for ; Fri, 15 Mar 2024 08:54:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D3D58010A; Fri, 15 Mar 2024 04:54:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 682FA800B4; Fri, 15 Mar 2024 04:54:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 487268010A; Fri, 15 Mar 2024 04:54:43 -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 3270B800B4 for ; Fri, 15 Mar 2024 04:54:43 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 04B10120B6A for ; Fri, 15 Mar 2024 08:54:42 +0000 (UTC) X-FDA: 81898662846.18.B243625 Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 5DAB4140002 for ; Fri, 15 Mar 2024 08:54:41 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Vce1JFmB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 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=1710492881; 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=3o3putACmh6pvZaB1O5h2PNuqzbzyiR0a61BH01Aa3w=; b=3W4fRAkRFOerxf6eabADz2IDtLwpavQeCDVnvV9z7J8UsVeG9ex00Fej49VbnLaj+a2fgg Gn7BuaQfXjASY1M4kAz5Kv2UNXhXnvrX7WqAOpaeWABFT/uDC9CvqmNt2+PaGaP7RQkLqM hEokXcejgN2mpatuGm9IxJGxaYccKdk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Vce1JFmB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710492881; a=rsa-sha256; cv=none; b=RWlGA+5rSpI4ttCCQ/9VyALrVuRaT73gOqvLIRJUbFn+LzjGNki+tlNv7s4JCTLSOR1WpH ilCHU6ckc7ZK2xrkWws8mPjzcGmbGrTxBBdHXGJkSDBXfR6bdAkDbpqyxIUrRVAJ88VAwM l8Ib4eY+17uKP0/vrLs/kFltdNTwT6U= Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-4d43a43c525so127154e0c.2 for ; Fri, 15 Mar 2024 01:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710492880; x=1711097680; 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=3o3putACmh6pvZaB1O5h2PNuqzbzyiR0a61BH01Aa3w=; b=Vce1JFmBTck8Q+Q5bN6GVCxe1GO9+5Q8S3RQqoxs6DCSOYpzSyF1A43z/a+TLH744O ns1XhIDeeDSjffHCH9oYQscQeFMnM7U/YsLBJuBqv4ZFXlQer0c19NZDhd8yo8r4WXYN fhge6EXnuo16DO3T2uBCmd24S1QD8wLYJNfWJOgd1HruGAGskHe/oDxPAd48zzjiuFXt UiCYSVhvJDezqpp89eKG2hwA5W9qypnopLptpxATPRvG8FFMjna6mjkpoSVZH7xURsjq 38PI1CH4QF4YYOqbFRYaa57XU61ADwTSD7CV//FpUyvoy8w8naC5NHsyUqfDU+evfjhd l4og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710492880; x=1711097680; 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=3o3putACmh6pvZaB1O5h2PNuqzbzyiR0a61BH01Aa3w=; b=CkrFRbqab4Ku01I8pOVDsrCApJ0KBK7ocdc8v4rd09j6Ct3ZVXDZhKloOKKTjZo5tq wchAy3p0FOz/ZMOaxKDq4QagHTQXOhYoiTkKdf+N75fm6lx+HcaIUYljwS9RDEGP7CCN M7aUwop6o+8brUhZadk/2MLKsTEnj2WpxjChsDJC26b/g+ieWsZYorqeGEvw7DSCgmD4 f+iul42KHoc47cjXPFrJYgTl24cUrV1lSDBFlcCVmL7loFa36B0TkKcU7KHMciIHnStD 6QCQURi8DA80Iw58T0TSZH6EULcF12US62/O6+XbVgtLp35Z+2ZfJwfgG5rdXKImrYc+ 7N4Q== X-Forwarded-Encrypted: i=1; AJvYcCX/KgOHIV8CRBPJYUnh1Y46xZC9j+lzDSHZ0q9spYlb/v9kwxCgSQHdQ0phXNHG79hNwGJxRkmyVhNOsGTw7CpunbU= X-Gm-Message-State: AOJu0YxBtcTL0sDLWnJAdrHo0j40LHwoaHeQQ/rKYZbCgSMrwIDtelI/ MtiFEhTYDdaCRRuKdTSGfwR7j9UbJU5uwOY17ECw0Hds2WcWDbA4J51p9YYwoOeliy4Hzb5NdEe dl/+Xp4ctZHKCI1CLPU/7Fa4HxXg= X-Google-Smtp-Source: AGHT+IFlSc4YIzOGH+cEsPWh2+3iHLC7a0Om34IIVLdDjrq1H0WV778wAKns3zhweO54J/S3on6vzfpaTN1ik88winQ= X-Received: by 2002:a05:6122:913:b0:4d3:3846:73bb with SMTP id j19-20020a056122091300b004d3384673bbmr5073768vka.7.1710492880515; Fri, 15 Mar 2024 01:54:40 -0700 (PDT) MIME-Version: 1.0 References: <20240304081348.197341-1-21cnbao@gmail.com> <20240304081348.197341-6-21cnbao@gmail.com> <87wmq3yji6.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87wmq3yji6.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Fri, 15 Mar 2024 21:54:29 +1300 Message-ID: Subject: Re: [RFC PATCH v3 5/5] mm: support large folios swapin as a whole To: "Huang, Ying" Cc: Matthew Wilcox , akpm@linux-foundation.org, linux-mm@kvack.org, ryan.roberts@arm.com, chengming.zhou@linux.dev, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mhocko@suse.com, nphamcs@gmail.com, shy828301@gmail.com, steven.price@arm.com, surenb@google.com, wangkefeng.wang@huawei.com, xiang@kernel.org, yosryahmed@google.com, yuzhao@google.com, Chuanhua Han , Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 8ioa97cuxpfy48gk7fbh7ad3aikk7bbp X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5DAB4140002 X-HE-Tag: 1710492881-277093 X-HE-Meta: U2FsdGVkX1924j+Iftva866ednUimyqMok5oi6jGVVu91+ypGzKMPV8GMzXHZCAy6tsd21Z4t510KFszcCmwza6JuanR9KCtiulBuPCHlnAlWfEtEYzx1hUwAVt2FNFscYQvSbFsf3K139Wjkbxibi/t1iV6l5IzGDGcWlI+wOe5oLlx3WIGPWtS/XRxiLDl4hEbeq9jQ10m4Rp0EQTTMKFWt2xx94p6VpivyKq3GG3jPmatO4EIqEJYTCMEgyQDkSWYLp+CK6EAcrcKtvK7/wfwiNE2AcO+beOJe/1LXxPX2JMHvz88zEjR+F3bI3WCFWCpujkwYHUW1d7stSVZihNNfm142g5Wg/SnSaDHUlHHIAYFATgbUgEFe9QXWdj73okvpzO422fsWmyDC5arNjicUQTQXng7dDIibOZM5kBSoIRjvaylnsBl28CLH+1KEqBi+yglXct+tpLkcB9LBZHZbCbL9kWYXn4aunO2kMyXRjhfIm1wKMzRTCJvIlB/niZIbvBJ8KGJG08VryCSd6ovtbkJEHoJBasHBR30Ior2JoydulMlGR7Mzz1rqydFj1dWy/VbVF8lvbtx/Gm+r8LdmyCyX20izRerLmGWNkCmbBKuDqK7GZQ7hYWXpXkMFMrtP9C4s3OlePaoj93+IE92Zeacon7PQ/KzVTABMBn4WOoZThtwcZ9q+l5/AhYBKLXej2ElMdCTHMJ91PtoCyDoYPO2q2Fau39DkQQEg8cRExwIUYr7tv7LK5+weCT6s1z1KPD0hB789XyAQ4EEAvw1Qva/DrbKGpPA09+qaw8MFwbs5x6k2MTHiGcZsMsVGJI4MUFf4UV346IShHL7u35j0aNN+lZxCH1TB0oRKFRkitvQiHvvoi8K9m261nzHItzDQht9GtS4QjLJglaGEsmSqJ1sieOsXcH0XPKV54hLocew7Z1Mb2o+hok3hepBNFGCaRcHjN6mDrF3TYw /eYPcKKf kOxy15XH/davUY5yEFfWYnbYxZ8iwg2U/VbC/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000978, 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 Fri, Mar 15, 2024 at 9:43=E2=80=AFPM Huang, Ying = wrote: > > Barry Song <21cnbao@gmail.com> writes: > > > From: Chuanhua Han > > > > On an embedded system like Android, more than half of anon memory is > > actually in swap devices such as zRAM. For example, while an app is > > switched to background, its most memory might be swapped-out. > > > > Now we have mTHP features, unfortunately, if we don't support large fol= ios > > swap-in, once those large folios are swapped-out, we immediately lose t= he > > performance gain we can get through large folios and hardware optimizat= ion > > such as CONT-PTE. > > > > This patch brings up mTHP swap-in support. Right now, we limit mTHP swa= p-in > > to those contiguous swaps which were likely swapped out from mTHP as a > > whole. > > > > Meanwhile, the current implementation only covers the SWAP_SYCHRONOUS > > case. It doesn't support swapin_readahead as large folios yet since thi= s > > kind of shared memory is much less than memory mapped by single process= . > > In contrast, I still think that it's better to start with normal swap-in > path, then expand to SWAP_SYCHRONOUS case. I'd rather try the reverse direction as non-sync anon memory is only around 3% in a phone as my observation. > > In normal swap-in path, we can take advantage of swap readahead > information to determine the swapped-in large folio order. That is, if > the return value of swapin_nr_pages() > 1, then we can try to allocate > and swapin a large folio. I am not quite sure we still need to depend on this. in do_anon_page, we have broken the assumption and allocated a large folio directly. On the other hand, compressing/decompressing large folios as a whole rather than doing it one by one can save a large percent of CPUs and provide a much lower compression ratio. With a hardware accelerator, this is even faster. So I'd rather more aggressively get large folios swap-in involved than depending on readahead. > > To do that, we need to track whether the sub-pages are accessed. I > guess we need that information for large file folio readahead too. > > Hi, Matthew, > > Can you help us on tracking whether the sub-pages of a readahead large > folio has been accessed? > > > Right now, we are re-faulting large folios which are still in swapcache= as a > > whole, this can effectively decrease extra loops and early-exitings whi= ch we > > have increased in arch_swap_restore() while supporting MTE restore for = folios > > rather than page. On the other hand, it can also decrease do_swap_page = as > > PTEs used to be set one by one even we hit a large folio in swapcache. > > > > -- > Best Regards, > Huang, Ying Thanks Barry