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 064A1C5478C for ; Mon, 26 Feb 2024 07:32:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 744FB6B010F; Mon, 26 Feb 2024 02:32:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CDA76B0111; Mon, 26 Feb 2024 02:32:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56F1C6B0113; Mon, 26 Feb 2024 02:32:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 473756B010F for ; Mon, 26 Feb 2024 02:32:07 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 14A381606C8 for ; Mon, 26 Feb 2024 07:32:07 +0000 (UTC) X-FDA: 81833136294.11.A2DBC58 Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by imf27.hostedemail.com (Postfix) with ESMTP id 5228040008 for ; Mon, 26 Feb 2024 07:32:05 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YxfiH3PD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.54 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=1708932725; 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=1UPIkE0QQTBljj0L7xZDdkALc4/UETjvnfFaRo5CwzM=; b=uRVr06xHZ99oU0l14Gp80A53sDNJHPJqqFcla65VYSlodwr8rbsNrJg3lXQqQQm2UeD0Fh 7fX2mpXveO0E3iV1MwXDxU/KJ10ali/C/FnMpPjwLq8eQkGB81iNb1vntfEEKlYjSYG/bZ W0xRXTRqnqkja53taBMqNFPnw+p7GLw= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YxfiH3PD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.54 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708932725; a=rsa-sha256; cv=none; b=L6+3o+Oy+fYEzW+IrGoBYqXOoaJ25FiN9gPiJUyNqywuNtLKBap49Xt4R82//Ksl2jWK/f nuLvBBJsAxiCaMuD5BAYNSbMgXgXf8teM8LdbiOJjoKRMIG+MUBSOoJFhVtM1vRzF+jBv6 UTw0EH+Rv2YBa4Bh5KK0Xdeg6Ge1Nfo= Received: by mail-ua1-f54.google.com with SMTP id a1e0cc1a2514c-7d698a8d93cso1593317241.3 for ; Sun, 25 Feb 2024 23:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708932724; x=1709537524; 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=1UPIkE0QQTBljj0L7xZDdkALc4/UETjvnfFaRo5CwzM=; b=YxfiH3PD4aVTyQRkmZn+VPM5JNdJ4CD1XeFcVFdW0UbikgPnDrFfXGDCGJaGmxt0wy fHp1s7zzSuX4qscZsdd4vnnJU6fdNQA/x5YUJUE0mfTfpVQwa6wjUY9MC+e5NEABLEEr vaszzZN8pj1scw8SkzHn2RWYSE8ouL7W4I1cL1MLdtKvJr7x+mDoWNsTedLmly07YTtJ 5BVsdKEJyu7Ch/VNygylCfdSYKtcQ8o9c+qpCQecPjELSwMwqQjsPk0C2nPdm/9PQw1n SlWfcdQVIivrH2Bi5lvuWqepgUVV3BEiTwW3bkShwDzQP+CiERLR0CUGTZxUUqw2sXcw kSOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708932724; x=1709537524; 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=1UPIkE0QQTBljj0L7xZDdkALc4/UETjvnfFaRo5CwzM=; b=DQ0bEy4t8AycJc72kK4a5Ah2sVZTX+bK/996mx3w7fqXYl+LS62nqjTd4K4nx6NQrF w2IKd+C9i8kyu3WDaKxa6jKiZhGWbZEIzCAS2wmT9bX0eb5ndoNSx/+/SldvnOVA2svs VSF+1/lUifrRgyYnVKV6D6VLD6vNGoAc5DEmZPRsVNVTU3zNd1Li1bIxkwTkBEEWYCaJ IUmg8gEl/byWJpuUmQzfy2uz3qPgirZ95axSOcPBogLn6cXV3J74HPCG7kizP2rYvG2R klj4bfWDuta5O2uwbaTnrGvzzPjiHwkzA2NFmDttfCXcLItTp1NeOKqZB1pPh/LP3Eo7 HKdw== X-Forwarded-Encrypted: i=1; AJvYcCUPewRfQWP+xGGw5X0O9QGox1pa9XAEWcfLSOhubXkkv8BsjZcFyUPsj9WNNM8SsryC9yKOorbfL4wx5veqlNeA4uA= X-Gm-Message-State: AOJu0YzC4KbBxjRAyqNYtberGuRjQ1kielJuCv1dH+/631mbff1/4hHB 4efGop47nKU2dbxj3rFKP2eM58+Ye1643Onb3lESVzp6dbFOOcXuXc4VEtfTwPUkBYJqis4RYVl rtYDMetI0X6i791dEvbnkrdyU1Yjl1EQ1+x8= X-Google-Smtp-Source: AGHT+IEIJS8GlMNMGiXIp5s/DhuyNL+jl4Bfn3hWIJCoIz/fCSUEW0uozunSiL551pqQhFJNsaoK5OqG3/XFxD47RxA= X-Received: by 2002:a05:6102:30a1:b0:470:5b6f:5ee9 with SMTP id y1-20020a05610230a100b004705b6f5ee9mr3850161vsd.17.1708932724347; Sun, 25 Feb 2024 23:32:04 -0800 (PST) MIME-Version: 1.0 References: <20231025144546.577640-1-ryan.roberts@arm.com> <20240118111036.72641-1-21cnbao@gmail.com> <20240118111036.72641-5-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 26 Feb 2024 20:31:53 +1300 Message-ID: Subject: Re: [PATCH RFC 4/6] mm: support large folios swapin as a whole To: Chris Li Cc: ryan.roberts@arm.com, akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.com, shy828301@gmail.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com, surenb@google.com, steven.price@arm.com, Chuanhua Han , Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5228040008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: hqyt3tpychjgbk6o4kitfjbtjt4xxusj X-HE-Tag: 1708932725-81582 X-HE-Meta: U2FsdGVkX1/MzjgJt5SbVvcY0KcVy4lOO+dxxywN3MRrzEM/LrMZjyGOt8c8N+BNSgTaWOmZeyqpLRsXjZMmrGNAwCDMO/u2Pm5RDb1WWwhzgGa7FuaBVq7myp+mXyQxvnvvxUYQ6jkIHLM+Gp2ecgEwVQiNzU1Be7O+BHFhWEpIneXahlL1J/kIURXNpeBRgoXzdmFhg1IMSqOC+YDvXZvoZQj/eTmuxkGx5MYL8Tvr5StS+qWfUOLtGE1vXXl5IVGDGFZw/MzZ75+6ZSwPedUKFryLfqHulJcKRFBYn+5rZsGd3yALF0+fPgBC6JbHKBuIF7cVZr552hyV9+v7bdq+9ry0BaRyZR7NM13w5cXgTNMZ3/1QEpjU6GSe8N8MtqkEFQ8inOmFtP+vSF/XkZfUtuM6PVbCkNTOP5E4hOiSDuMsfH8flr5EiUP0Zeo+Kbx8cOie10dMKt5pjZGhTimcqQYeUBGaZFsTTWUgY/O3xUST7vASE3ZrnqocSTdBUJuSnuBGiAcisKFtGx26GbIL//DC7jntaJb9Tkwe8ywI0xIS290GFxVzo20Z5ylEH42FBc20WsBFWWwcvjmusxrlep0JclIW4NKG9ghHFfQUI1uyuuPh3dIHNJjuQwujrbs3iRum4yJ2MVWU7V3BLy0jRSbrQsGfMXAdoPqCL5zffyBbgqwLdnrfiEWs6flcoveg7Qz66BFpqdCui42DjLo+vmibjoNsfoRkVbElc12gni6JLb/n0DfHhEIbxOwgVD3v6t2zaryt7dydy+v38wbLm6EoUgKCz/ytGWjSPZzEmcr/o4++EQh+7ESYAEN9twKVBA0GAZYVpS7rmiwpNFq2JZhSx58c0oFcepgIp6HqCtPttr4YsAnYWuPYFF+gioMCA1frAgq32EneaiESFJJchO5TvqPBnufGoTBpNQ97p+JVmLGUAJfom/Ra1dj36hMChBJvYivMcyfO6wy 6wIQlzPl 4tFj4zXdIN4+0Z680Jw0t+PliwIZeeN2AEWYkfq4JHQD9GAYxxbI5yIgHWDEGZEPSjFq5sR7QR0yss7gLCVjD2o7xBtT8RFzhpa2Yt4DUEuDeQbIINa8EqaKPUw1XHFUBzav6WtDuF5YjOQreApvCImJ5mOxQSY70uK0g/Z51sJ+UMwmgk5lSSBBcLfOPonYmv2dNlDPgzsDdzTXNEFwXWa+iops6iBto2bIdbfiH9X/s6oMjJwxm3FSVdDgWowBuQXAkiFIjvkHwhkEzS8N7BUKsOrL+tS5TDzPg7mbk5KFmtUAguwPNCnmZLMiOciSlsd9dJZp/OYn2sD1tFITup2fbbm/nAa/TR8yX00mieZXqelrhHd+G6Pvgq8kRYlsC3FRGfvsFnk2o4v2yjQs0Rix9eUkkHsAaA9gVFiKBtEHn58JFSJJu4o4529hKZ/+8RKDRf3fIbFqnFQyrRwcIBE0Q6zX9ZNbbConb4MCimdD0vNnXIKy6vr4D2w== 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 Sun, Jan 28, 2024 at 9:06=E2=80=AFAM Chris Li wrote: > > On Thu, Jan 18, 2024 at 3:12=E2=80=AFAM Barry Song <21cnbao@gmail.com> wr= ote: > > > > From: Chuanhua Han > > > > On an embedded system like Android, more than half of anon memory is ac= tually > > in swap devices such as zRAM. For example, while an app is switched to = back- > > ground, 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. > > > > On the other hand, the current implementation only covers the SWAP_SYCH= RONOUS > > case. It doesn't support swapin_readahead as large folios yet. > > > > 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. > > > > Signed-off-by: Chuanhua Han > > Co-developed-by: Barry Song > > Signed-off-by: Barry Song > > --- > > mm/memory.c | 108 +++++++++++++++++++++++++++++++++++++++++++++------- > > 1 file changed, 94 insertions(+), 14 deletions(-) > > > > diff --git a/mm/memory.c b/mm/memory.c > > index f61a48929ba7..928b3f542932 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -107,6 +107,8 @@ EXPORT_SYMBOL(mem_map); > > static vm_fault_t do_fault(struct vm_fault *vmf); > > static vm_fault_t do_anonymous_page(struct vm_fault *vmf); > > static bool vmf_pte_changed(struct vm_fault *vmf); > > +static struct folio *alloc_anon_folio(struct vm_fault *vmf, > > + bool (*pte_range_check)(pte_t *, = int)); > > > > /* > > * Return true if the original pte was a uffd-wp pte marker (so the pt= e was > > @@ -3784,6 +3786,34 @@ static vm_fault_t handle_pte_marker(struct vm_fa= ult *vmf) > > return VM_FAULT_SIGBUS; > > } > > > > +static bool pte_range_swap(pte_t *pte, int nr_pages) > > +{ > > + int i; > > + swp_entry_t entry; > > + unsigned type; > > + pgoff_t start_offset; > > + > > + entry =3D pte_to_swp_entry(ptep_get_lockless(pte)); > > + if (non_swap_entry(entry)) > > + return false; > > + start_offset =3D swp_offset(entry); > > + if (start_offset % nr_pages) > > + return false; > > + > > + type =3D swp_type(entry); > > + for (i =3D 1; i < nr_pages; i++) { > > + entry =3D pte_to_swp_entry(ptep_get_lockless(pte + i)); > > + if (non_swap_entry(entry)) > > + return false; > > + if (swp_offset(entry) !=3D start_offset + i) > > + return false; > > + if (swp_type(entry) !=3D type) > > + return false; > > + } > > + > > + return true; > > +} > > + > > /* > > * We enter with non-exclusive mmap_lock (to exclude vma changes, > > * but allow concurrent faults), and pte mapped but not yet locked. > > @@ -3804,6 +3834,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > pte_t pte; > > vm_fault_t ret =3D 0; > > void *shadow =3D NULL; > > + int nr_pages =3D 1; > > + unsigned long start_address; > > + pte_t *start_pte; > > > > if (!pte_unmap_same(vmf)) > > goto out; > > @@ -3868,13 +3901,20 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > if (data_race(si->flags & SWP_SYNCHRONOUS_IO) && > > __swap_count(entry) =3D=3D 1) { > > /* skip swapcache */ > > - folio =3D vma_alloc_folio(GFP_HIGHUSER_MOVABLE,= 0, > > - vma, vmf->address, fals= e); > > + folio =3D alloc_anon_folio(vmf, pte_range_swap)= ; > > page =3D &folio->page; > > if (folio) { > > __folio_set_locked(folio); > > __folio_set_swapbacked(folio); > > > > + if (folio_test_large(folio)) { > > + unsigned long start_offset; > > + > > + nr_pages =3D folio_nr_pages(fol= io); > > + start_offset =3D swp_offset(ent= ry) & ~(nr_pages - 1); > > + entry =3D swp_entry(swp_type(en= try), start_offset); > > + } > > + > > if (mem_cgroup_swapin_charge_folio(foli= o, > > vma->vm_mm, GFP= _KERNEL, > > entry)) { > > @@ -3980,6 +4020,39 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > */ > > vmf->pte =3D pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->add= ress, > > &vmf->ptl); > > + > > + start_address =3D vmf->address; > > + start_pte =3D vmf->pte; > > + if (folio_test_large(folio)) { > > + unsigned long nr =3D folio_nr_pages(folio); > > + unsigned long addr =3D ALIGN_DOWN(vmf->address, nr * PA= GE_SIZE); > > + pte_t *pte_t =3D vmf->pte - (vmf->address - addr) / PAG= E_SIZE; > > I forgot about one comment here. > Please change the variable name other than "pte_t", it is a bit > strange to use the typedef name as variable name here. > make sense! > Chris Thanks Barry