From patchwork Wed Feb 1 08:17:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yin Fengwei X-Patchwork-Id: 13123910 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 41DABC38142 for ; Wed, 1 Feb 2023 08:15:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A528E6B0078; Wed, 1 Feb 2023 03:15:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98D416B007B; Wed, 1 Feb 2023 03:15:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E0BD6B007D; Wed, 1 Feb 2023 03:15:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 619D76B0078 for ; Wed, 1 Feb 2023 03:15:58 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2131B1A0498 for ; Wed, 1 Feb 2023 08:15:58 +0000 (UTC) X-FDA: 80418014796.11.93EB691 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf17.hostedemail.com (Postfix) with ESMTP id CC80140015 for ; Wed, 1 Feb 2023 08:15:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Ao3bG/LJ"; spf=pass (imf17.hostedemail.com: domain of fengwei.yin@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675239356; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UJUMh6py4O0Tr+jNGUObiyCKiauCrv4jrbrkHaA7X3Y=; b=hZwqIfOp04+DI3xlk3vSvYxQlfvskJdKyZ5Oj+gZ61BdHrYcQMt2rxzSp8XfrD0xLYjKFf nwYaL7uN5RBuwt0KSpZBPYBqdPDtl9uj1bp6XHn0DWyEfOU4ZU+Rg6WcavQtwfx4qNBcVF E8zyXrghvPziUkY9PaA9GO9cAVwq5XA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Ao3bG/LJ"; spf=pass (imf17.hostedemail.com: domain of fengwei.yin@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675239356; a=rsa-sha256; cv=none; b=A7xzk4seNB2XqhYiJMJV96CmNOLzOrf2K7dAnFYr3Bwf5/zZAYojG988ED0LisWNF7+v4z iti/TQqnPPvzQ9wZY03wueGFmH5otbGufYeEGfBxWX3IrKas8JOkpCqgmGoJ/0MriHW4jT RclOtncrEzJuxSBkCNUIz+6mpRWCjmg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675239356; x=1706775356; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Gq3LL1aqVMDzRz4yoac8QrMuaWFnU+iYFwQ79VrezwE=; b=Ao3bG/LJno+J/oKZKSth2wVk0Sx52ES2Ac5tIGPEfrHV/suNjWGas4ek mrF92FhOeHT0Bdzu0uwu6M53eDzd7BlisglMfi+oPwYojWOJi/DWncKeA yM+4LSlNx0inX39dlDdwQJX97xEILEuu6ebGY87RYINjDhhHfZX85wRAh zEJffCT0Ah5ALnMJx+Pz8pD0wCflvdbacBwNgLbXPHX0ITPqElf792EjU tCbHaEuNASy9cLou6xUTtDdS5gAWEezyrr0R/V3UjJp451BNNIGM9641P wIK4x+MSgLMRieb5+3tiFiuD/VT1QCsuKSvC/vr43DY5FQK57Q18RWygc A==; X-IronPort-AV: E=McAfee;i="6500,9779,10607"; a="390471685" X-IronPort-AV: E=Sophos;i="5.97,263,1669104000"; d="scan'208";a="390471685" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Feb 2023 00:15:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10607"; a="753580331" X-IronPort-AV: E=Sophos;i="5.97,263,1669104000"; d="scan'208";a="753580331" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by FMSMGA003.fm.intel.com with ESMTP; 01 Feb 2023 00:15:50 -0800 From: Yin Fengwei To: willy@infradead.org, david@redhat.com, linux-mm@kvack.org Cc: dave.hansen@intel.com, tim.c.chen@intel.com, ying.huang@intel.com, fengwei.yin@intel.com Subject: [RFC PATCH v2 2/5] filemap: add function filemap_map_folio_range() Date: Wed, 1 Feb 2023 16:17:34 +0800 Message-Id: <20230201081737.2330141-3-fengwei.yin@intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230201081737.2330141-1-fengwei.yin@intel.com> References: <20230201081737.2330141-1-fengwei.yin@intel.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: boibibnponsnwunx7a3bit6itykx634f X-Rspamd-Queue-Id: CC80140015 X-HE-Tag: 1675239355-848600 X-HE-Meta: U2FsdGVkX18c7rAkPklsytO5OBmvU6oBuaIwOqh9SyIxA7HTI3drBS4RdNkfmhEXnSPVar5JcU2Im47AdcyOlmb2a9jHY3+YTkKIimPYiv4RYw+e2oA8ekX567op6cLV1kzfyi7bUq6Q88zLcnAKtsxKpjkTdxbSlWvhNUypSyVFNouroAnp9wE06yMz3/8pXr9OmnNmo7rklGGDZAwAOlWX36oKi2t8Euohpktvvya7YOBUl7lvdGw42IkdpB4JKPGn8VvrUa3it6x8pmITdX/MlOgo0jBZFSVg2R7AazvKJTd9ibqyPhnsao212M5whrSV/ClJk7OfpIlTynEWmAIEHJHkQygGJ2BtawKJTOjqXZfrF/766RZ/vfQ5DNVTQN/z/yLBLWxM9OisUNV2fEPnexsGxjoO4KVEXQkQ0U1FG+hLppqlcYDKZCw7iiwSBEkaJp5Fah9XnAJNpFWVJyWvcZ+/XAaZaqGjQ9I2+iv1NKqLT8QkJCPJGkpfpgn58W6/Rn/A6fKCN8hDT33YzGA3IQHA6RKYsXCvClUdZm7iA1naKkPJ68R7NrmSuAPztKnzzGFbEToabNokZ2nrE6UwJo4Xu7J2B6EKuIGkI11Uz6vzE8jKu2SItiwwFD6kycR+Y98Ns+YMj/UkjjdlWEU8/ef8OIdTtQRJOcreJ+mOClph+ygWODNqqEsY/CSyl/q9GVp1k/Ra4l2/NY81oEn2precSiuznDxY4XU5F1980I5hRYCPOb7CQDZndF4uiaV5c4reQr2aqZgiHfLYZdlYC63XSq0w6kemIuwFHTsuJ2xYE5IVS2JypSHNHxweeE7TmIWsVYwnopw/EzbpbXI3uCpk25bluQbwqnDVfvQsDy3v5ZDlGx1dnjV14f2LtkuIAzerTJAv2IDlOzU739DWFEiTSBR4bdnNTX1yy+EBrOa2FAD7B3XbodTzgaWiqgEkNXCJlb63mFOd3Zm oEm3fYy7 mpStDPpDry06TAvtSynUqaotIWpXmhTTkaCp0WIZLdzDpFl+tzVdV6mbn6zKPV42a8HRHoHgz+tUoNiE+MXJXZamjK/qvnUGxXdUHyY/ITWIneQ1yO4y6RBbEK3MPE3n1LnL9QMwgAqcEQ5TrrsEFclUshurP0Mtan8uz1c7I3QMj51d8/AEmBnPM+ajOCAosDc7KeZZESctP8rs13NNiSnBq5g== 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: filemap_map_folio_range() maps partial/full folio. Comparing to original filemap_map_pages(), it batched updates refcount and get minor performance improvement for large folio. a self cooked will-it-scale.page_fault3 like app (change file write fault to read fault) with xfs filesystem got 2% performance gain. Signed-off-by: Yin Fengwei --- mm/filemap.c | 91 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 57 insertions(+), 34 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 992554c18f1f..9cc5edd8f998 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3351,6 +3351,56 @@ static inline struct folio *next_map_page(struct address_space *mapping, mapping, xas, end_pgoff); } +/* + * Map sub-pages range [start_page, start_page + nr_pages) of folio. + * start_page is gotten from start by folio_page(folio, start) + */ +static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, + struct folio *folio, unsigned long start, + unsigned long addr, unsigned int nr_pages) +{ + vm_fault_t ret = 0; + struct vm_area_struct *vma = vmf->vma; + struct file *file = vma->vm_file; + struct page *page = folio_page(folio, start); + unsigned int mmap_miss = READ_ONCE(file->f_ra.mmap_miss); + unsigned int ref_count = 0, count = 0; + + do { + if (PageHWPoison(page)) + continue; + + if (mmap_miss > 0) + mmap_miss--; + + /* + * NOTE: If there're PTE markers, we'll leave them to be + * handled in the specific fault path, and it'll prohibit the + * fault-around logic. + */ + if (!pte_none(*vmf->pte)) + continue; + + if (vmf->address == addr) + ret = VM_FAULT_NOPAGE; + + ref_count++; + do_set_pte(vmf, page, addr); + update_mmu_cache(vma, addr, vmf->pte); + } while (vmf->pte++, page++, addr += PAGE_SIZE, ++count < nr_pages); + + /* + * Restore the vmf->pte. Otherwise, it's possible vmf->pte point + * to next page table entry if the last sub page in the range is + * mapped to the last entry of page table. + */ + vmf->pte -= nr_pages; + folio_ref_add(folio, ref_count); + WRITE_ONCE(file->f_ra.mmap_miss, mmap_miss); + + return ret; +} + vm_fault_t filemap_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff) { @@ -3361,9 +3411,9 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf, unsigned long addr; XA_STATE(xas, &mapping->i_pages, start_pgoff); struct folio *folio; - struct page *page; unsigned int mmap_miss = READ_ONCE(file->f_ra.mmap_miss); vm_fault_t ret = 0; + int nr_pages = 0; rcu_read_lock(); folio = first_map_page(mapping, &xas, end_pgoff); @@ -3378,45 +3428,18 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf, addr = vma->vm_start + ((start_pgoff - vma->vm_pgoff) << PAGE_SHIFT); vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl); do { -again: - page = folio_file_page(folio, xas.xa_index); - if (PageHWPoison(page)) - goto unlock; - - if (mmap_miss > 0) - mmap_miss--; + unsigned long end; addr += (xas.xa_index - last_pgoff) << PAGE_SHIFT; vmf->pte += xas.xa_index - last_pgoff; last_pgoff = xas.xa_index; + end = folio->index + folio_nr_pages(folio) - 1; + nr_pages = min(end, end_pgoff) - xas.xa_index + 1; - /* - * NOTE: If there're PTE markers, we'll leave them to be - * handled in the specific fault path, and it'll prohibit the - * fault-around logic. - */ - if (!pte_none(*vmf->pte)) - goto unlock; - - /* We're about to handle the fault */ - if (vmf->address == addr) - ret = VM_FAULT_NOPAGE; + ret |= filemap_map_folio_range(vmf, folio, + xas.xa_index - folio->index, addr, nr_pages); + xas.xa_index = end; - do_set_pte(vmf, page, addr); - /* no need to invalidate: a not-present page won't be cached */ - update_mmu_cache(vma, addr, vmf->pte); - if (folio_more_pages(folio, xas.xa_index, end_pgoff)) { - xas.xa_index++; - folio_ref_inc(folio); - goto again; - } - folio_unlock(folio); - continue; -unlock: - if (folio_more_pages(folio, xas.xa_index, end_pgoff)) { - xas.xa_index++; - goto again; - } folio_unlock(folio); folio_put(folio); } while ((folio = next_map_page(mapping, &xas, end_pgoff)) != NULL);