From patchwork Fri Feb 3 13:16:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yin Fengwei X-Patchwork-Id: 13127502 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 10084C05027 for ; Fri, 3 Feb 2023 13:14:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9479C6B0075; Fri, 3 Feb 2023 08:14:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CFFA6B0078; Fri, 3 Feb 2023 08:14:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 749A26B007B; Fri, 3 Feb 2023 08:14:50 -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 6788D6B0075 for ; Fri, 3 Feb 2023 08:14:50 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 42DBD804D6 for ; Fri, 3 Feb 2023 13:14:50 +0000 (UTC) X-FDA: 80426025540.26.7A9969E Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP id 36BC31C0009 for ; Fri, 3 Feb 2023 13:14:47 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DZA+aYuD; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675430088; 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=PkN3M8JdvU4YbbZ+vqRS95i4OQTeEU6UDDCzY0xrouU=; b=Iqv62jwT3Zy/gLBiiD7swoOEl4ti2SYoubNbNqhxlvwZdI5JNPpVA9kcog9jcD7glmFZ2D Po34ILhyXQyBgWES0ktUFUP3rCIpltUaYLfKJ8RY2jS8zpaTkNjRDANH01jjsUkUreSyJk LSN62Y0N0nkCV63KszFmkdS1IFOMH10= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=DZA+aYuD; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf18.hostedemail.com: domain of fengwei.yin@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=fengwei.yin@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675430088; a=rsa-sha256; cv=none; b=WJi3FrGcZu3rgWV58zgyYhAUnHs127hpm9jfmq5Ay68MaLbFcM7LqAGSPgC9QwkditW62q WfWyhP0IWHWtnnhVpmKDmROB+1gTBf4XdUT7dXi7Y8g92kd94TWiePV3j1DZ3aQRltea4o dLggdbxXxaWERnMzEwqyx3D6Y+ihanQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675430088; x=1706966088; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=3bf4l263P9fVufjhv5VLZbFxEerrnvzLFxKFmK42Ng0=; b=DZA+aYuD3EXHWodyWe3BJcjhQzy/jpyuRef/Rtw79XH3LxJKAdEyCCMS VTe23WTsdz1Xh+nmJ0dL0MlcnLyeWmHbibuMLQ0POL8IZL3Km1amHeHiD Dj0FWw+uSGLtHVnQP+hp2/tOhplbOCl9SzwH2RrPj14SvL4jJUDB71LyJ KLRrcX7/nMf+0HOlTrJ0uzraE9BpmzYFgoNx3kvzguPNV0gsFnR5K6mLF z/R+cArLWn5BTEWmIow0TrFNbEvmOkwekE//kZCi1cDWdpK4udOIAwgb0 EiqKkoAwgvwzkwD2ZdcvvR2GJVLfidQiclCnZUweivbk/1a1uRgl2Ke4K g==; X-IronPort-AV: E=McAfee;i="6500,9779,10609"; a="326441885" X-IronPort-AV: E=Sophos;i="5.97,270,1669104000"; d="scan'208";a="326441885" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Feb 2023 05:14:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10609"; a="667641943" X-IronPort-AV: E=Sophos;i="5.97,270,1669104000"; d="scan'208";a="667641943" Received: from fyin-dev.sh.intel.com ([10.239.159.32]) by fmsmga007.fm.intel.com with ESMTP; 03 Feb 2023 05:14:45 -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 v3 1/4] filemap: add function filemap_map_folio_range() Date: Fri, 3 Feb 2023 21:16:33 +0800 Message-Id: <20230203131636.1648662-2-fengwei.yin@intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230203131636.1648662-1-fengwei.yin@intel.com> References: <20230203131636.1648662-1-fengwei.yin@intel.com> MIME-Version: 1.0 X-Rspamd-Queue-Id: 36BC31C0009 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 7i1bfgfsadhu384yh1w3jndxnmjkkquk X-HE-Tag: 1675430087-648291 X-HE-Meta: U2FsdGVkX1/uqq5QoBX/O9TvvxFAuAiNE5oZCVNIvV1kYcpdrRVQb4yIbNtD1BIA29SEUNoygveQQi1P3hx04Y5K28GSwL55U7AWlkL4A4HGlnCcj6jjFIULYoMvE2YB7rPYQebuYteOBpI9z42M61OAFnWwfDxU6sEm1bU5+0N829M5FcZb3hKmnGV5PXLz7EsgW9GUe70qRZ/pEKsmJDCRpd7nTSqwl9caBC16BqQB3XqXD9GLiQRp/XTrrU1dz7yRAe7wFk9Z4JJFCD/hq7SOtyI9zMGNYooHx4C6UKb4VLoE46MmXCwlLVInOwXIFaqr5dzRFP480fYjzpihd7vcreig22+VoVo9WlgkBWnWTRvxGBC3S2vY7q45mCbxJRk8Lo4+eTuslXr0x9Q28+soEdlQPTx7LwdwN/Jh0HQx6pay2wl0xgOQOnOhahIWQBe3SHUxBKTgOBb+T7EbrVdgb4o4sVUDuI2eR2IKsk+Yg/Mf9RvDW93DzWpPh1UvBXS37aKFCBTQtRHwzlg43b3lpLVfIQ06DxJEPz3hFAadOFjf3gUXb1fH1gXSBeYKWGAeKw8+csxKV1wIQ7AxqZ2JAUZ9IqQ8uIf/dWX27kqCP5jnuVik3SGnls/muuzPtb7qTANbOMeYXfmu7cwIPMK8QMCVFZCiZoLBXjByS938LMqCkwJir96ENrsq5uuRb9Ec0GuKxncI6wtLPk7eyCx4TGeYmvRZykmVa0S85J7Pb1yGt1A2mipuL27urLRUM9yoZYipOvzh3LO4yukKCLfG9e8FID/O7F4rzuaSzn3AC7JKdlgAoFW9OO+JPiJYnoPi6YbsMG27B3ZVFmswOa9ZpH75XXB0Dwvk2s/uwgkVm5Tz8rCePR25eYqYLivrKWL8WG8wnd1GjY39jV0OKTp+AKLZSf6OWDQid+ofPzz9oembCtWFvJBxZJmFzHfOUWFcExpRfHoWpQTTT4i 3q9KpPlv F/4N6k+/JsB9K3zR23o6cU5piOnBJVDcaAv71O1LAkN5PUkVot9YfO0pHORckQZkWGwxFlQYFbM2UfqjVr1zz/vaiDUJlX5NKRCMeQuSLXYzEw7O+7Pk6g1obVw32lDObPgAfqhzBsvAhNFATDTmuicBQHTKeYv/AgR7/6VhI1rP3OacCPcPQgkluXj453CBh6mwVOVYlZZPR0aWkPtRcZi/LsQ== 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 | 88 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 54 insertions(+), 34 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 992554c18f1f..f444684db9f2 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3351,6 +3351,53 @@ 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 */ + 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 +3408,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 +3425,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);