From patchwork Thu Feb 29 06:09:07 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peng Zhang X-Patchwork-Id: 13576506 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 8D596C48BF6 for ; Thu, 29 Feb 2024 06:09:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF69E6B0099; Thu, 29 Feb 2024 01:09:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7F796B009A; Thu, 29 Feb 2024 01:09:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 947CC6B009B; Thu, 29 Feb 2024 01:09:33 -0500 (EST) 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 7F2956B0099 for ; Thu, 29 Feb 2024 01:09:33 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3D19A140203 for ; Thu, 29 Feb 2024 06:09:33 +0000 (UTC) X-FDA: 81843814626.10.78953BD Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf04.hostedemail.com (Postfix) with ESMTP id 578B140017 for ; Thu, 29 Feb 2024 06:09:28 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of zhangpeng362@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=zhangpeng362@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709186970; a=rsa-sha256; cv=none; b=sZsyiLN+aYR6yi4N6qUCpvSgrrCBMBpimsNxR/l0ARhUg9WVrMZ1qaFZcx2k1tCrvfootO vtBmD6M2MB8s66x3MetGFy0sLMlqdjvsdGtGVIrtfQL+s2/Y8jYZPOSTJFizhV+ZECuZqu d01kNcBD987cZOKrGElNUnJqBsniMTI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf04.hostedemail.com: domain of zhangpeng362@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=zhangpeng362@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709186970; 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: references; bh=PsYHfkepqgSq+4yroC8oL5snXBDrOe84TnLYYeqyVT0=; b=CEkHtsFuza/ZNYzzGcuvgHZ8QlIn5KnTgOlRlU+21xaGenJ6fjxjVCCdo+Es1QZl2xkMHt nrF3gb72NFP/xVfmUOLvZJG7d9ZdyOoiZUib88+e8nFE9nXFOtbCfeIxd7+kgO4YqB1UZa dWPtQYrRnys3UrXgKLA5Kz1Pd/E1vGM= Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Tlgm3152cz1FLNZ; Thu, 29 Feb 2024 14:09:23 +0800 (CST) Received: from kwepemm600020.china.huawei.com (unknown [7.193.23.147]) by mail.maildlp.com (Postfix) with ESMTPS id 8CCBD1A0172; Thu, 29 Feb 2024 14:09:24 +0800 (CST) Received: from localhost.localdomain (10.175.112.125) by kwepemm600020.china.huawei.com (7.193.23.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 29 Feb 2024 14:09:23 +0800 From: Peng Zhang To: , CC: , , , , , , , , , , Subject: [PATCH v3] filemap: avoid unnecessary major faults in filemap_fault() Date: Thu, 29 Feb 2024 14:09:07 +0800 Message-ID: <20240229060907.836589-1-zhangpeng362@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.175.112.125] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To kwepemm600020.china.huawei.com (7.193.23.147) X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 578B140017 X-Stat-Signature: 6m7egwe49r8ddeq76seo5xh7n5wbww47 X-Rspam-User: X-HE-Tag: 1709186968-952030 X-HE-Meta: U2FsdGVkX19ZgsSeOAu1PwafDsJuhg6Td28xm4ejP5+EYv7DmTI5RLxQWa4XYLmV3WkK32i9ssWDINW/vt1NjNuFBqQWq+codKcxHrYHIf0+kl2VE19/DaDSpHFbsQAj+6wkK3bub5bozHPxYov9JiUTTVGWu6F2XwUCLI+pHoM2iHCaozipXmv2hyrXQ1uP4QEAhVj4UWy1G0MDkOIHRuhNd4A3Kecg3xZbmyUYzno1rFdVg5u1V3+jDJWwQpI50j9rIDG/Fh70Vnn23SHYVVWfhQ1crY0d53pHpuE/8azM6p2XTt0/9FuCJeZRUCvR9KOeX6jyyfNOZbhRFr00Squ8YUkhfNSEoWiH5UOvdpK0kWF1sbTRFP68L8l06jzMi0b0G130rnWOOSyU+nFHtGW05T4MLWl6AjCGYBoZnF+03XgmPh4++odiC8MbeL+Ean6AMlp+Tr9axmlX4Q5ZdrwrBm++bHqt6s81ytYk7rIqBV8diINed9LwUVZ4t2P/4UW4pl4eYwJ3RcaPqVEh+Z49xOlvvLeUuVzQz45f8mzp5T/dcTwQSlHvE1/jydVa5dvcfDDd/xvWFLU3t+TaiMXd1lM7wZLj7H7PtLmbWUDGHB+FVSOnjVPVM0Xn95c0kNhMR9p7UVL3gzW8G1I1ucx42TTCs6ElqPLKQOygHo9Sf8rNBXkdEi0gF7f/qz7yU8HcvBj7HWygPNTGYI1bsvokb2t0J6AFPnRdHm5L2TzF5i7v/9S9eMuQQ+JVK5GegwCB7kJEepJZDv2xyvcj+axFbq4BxaVll3lGCG/hvRbQpBxeRFyj2ymoCd7Z/ysVXr8CnXNerf5WVavENukxpSSb8MVWvme7W07Ki+XzTB88c4Xaqw7Nf5CSpwpGWNo5t/PxjIwGXwkxe2XKvMtE8SXwKe+nnOh6KKXj/APB/+NjMcJuH5VnmM5fpdGkZktgWTSA4gRNrRF9S3SnFea PmnuKrce UOEf0uQotwPldg1VX2Vki3lCeRURO6vBsATNLxVbu74bT1KCQHKRq7B1YBIetnrzphfmVsGia3SafZyIIQzjs0FR64OLj0z+ADc7zbJ3KL3vT8ePXy8P33YGdRbCv+WgKR1dWgDG0WjGlw0clAVI03nOSquQFCeHP/q6CKYt1Gi22T6zrkbw7oU+cLFLlHSNBMRWXF2ANRHY+YSQzjI4a2XSerjbLZaeLKq09WqF4agFadNy2YifhIpYRYtFNpt+7bHGCivKOLJE9rzRvlFjLYRKguVJqyu9X29eOWGnxZmb/Mhr//F2kvRxB2a9cUBSR6dkl 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: From: ZhangPeng The major fault occurred when using mlockall(MCL_CURRENT | MCL_FUTURE) in application, which leading to an unexpected issue[1]. This caused by temporarily cleared PTE during a read+clear/modify/write update of the PTE, eg, do_numa_page()/change_pte_range(). For the data segment of the user-mode program, the global variable area is a private mapping. After the pagecache is loaded, the private anonymous page is generated after the COW is triggered. Mlockall can lock COW pages (anonymous pages), but the original file pages cannot be locked and may be reclaimed. If the global variable (private anon page) is accessed when vmf->pte is zeroed in numa fault, a file page fault will be triggered. At this time, the original private file page may have been reclaimed. If the page cache is not available at this time, a major fault will be triggered and the file will be read, causing additional overhead. This issue affects our traffic analysis service. The inbound traffic is heavy. If a major fault occurs, the I/O schedule is triggered and the original I/O is suspended. Generally, the I/O schedule is 0.7 ms. If other applications are operating disks, the system needs to wait for more than 10 ms. However, the inbound traffic is heavy and the NIC buffer is small. As a result, packet loss occurs. But the traffic analysis service can't tolerate packet loss. Fix this by holding PTL and rechecking the PTE in filemap_fault() before triggering a major fault. We do this check only if vma is VM_LOCKED. In our service test environment, the baseline is 7 major faults / 12 hours. After the patch is applied, no major fault will be triggered. Testing file anonymous page read and write page fault performance in ext4, tmpfs and ramdisk using will-it-scale[2] on a x86 physical machine. The data is the average change compared with the mainline after the patch is applied. The test results are indicates some performance regressions. We do this check only if vma is VM_LOCKED, therefore, no performance regressions is caused for most common cases. The test results are as follows: processes processes_idle threads threads_idle ext4 private file write: -0.51% 0.08% -0.03% -0.04% ext4 shared file write: 0.135% -0.531% 2.883% -0.772% ramdisk private file write: -0.48% 0.23% -1.08% 0.27% ramdisk private file read: 0.07% -6.90% -5.85% -0.70% tmpfs private file write: -0.344% -0.110% 0.200% 0.145% tmpfs shared file write: 0.958% 0.101% 2.781% -0.337% tmpfs private file read: -0.16% 0.00% -0.12% 0.41% [1] https://lore.kernel.org/linux-mm/9e62fd9a-bee0-52bf-50a7-498fa17434ee@huawei.com/ [2] https://github.com/antonblanchard/will-it-scale/ Suggested-by: "Huang, Ying" Suggested-by: David Hildenbrand Signed-off-by: ZhangPeng Signed-off-by: Kefeng Wang --- v2->v3: - Do this check only if vma is VM_LOCKED per David Hildenbrand - Hold PTL and recheck the PTE - Place the recheck code in a new function filemap_fault_recheck_pte() v1->v2: - Add more test results per Huang, Ying - Add more comments before check PTE per Huang, Ying, David Hildenbrand and Yin Fengwei - Change pte_offset_map_nolock to pte_offset_map as the PTL won't be used RFC->v1: - Add error handling when ptep == NULL per Huang, Ying and Matthew Wilcox - Check the PTE without acquiring PTL in filemap_fault(), suggested by Huang, Ying and Yin Fengwei - Add pmd_none() check before PTE map - Update commit message and add performance test information mm/filemap.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index b4858d89f1b1..2668bac68df7 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -3181,6 +3181,42 @@ static struct file *do_async_mmap_readahead(struct vm_fault *vmf, return fpin; } +/* + * filemap_fault_recheck_pte - hold PTL and recheck whether pte is none. + * @vmf - the vm_fault for this fault. + * + * Recheck PTE as the PTE can be cleared temporarily during a read+clear/modify + * /write update of the PTE, eg, do_numa_page()/change_pte_range(). This will + * trigger an unexpected major fault, even if we use mlockall(), which may + * increase IO and thus cause other unexpected behavior. + * + * Return VM_FAULT_NOPAGE if the PTE is not none or pte_offset_map_lock() + * fails. In other cases, 0 is returned. + */ +static vm_fault_t filemap_fault_recheck_pte(struct vm_fault *vmf) +{ + struct vm_area_struct *vma = vmf->vma; + vm_fault_t ret = 0; + pte_t *ptep; + + if (!(vma->vm_flags & VM_LOCKED)) + return ret; + + if (pmd_none(*vmf->pmd)) + return ret; + + ptep = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address, + &vmf->ptl); + if (unlikely(!ptep)) + return VM_FAULT_NOPAGE; + + if (unlikely(!pte_none(ptep_get(ptep)))) + ret = VM_FAULT_NOPAGE; + + pte_unmap_unlock(ptep, vmf->ptl); + return ret; +} + /** * filemap_fault - read in file data for page fault handling * @vmf: struct vm_fault containing details of the fault @@ -3236,6 +3272,10 @@ vm_fault_t filemap_fault(struct vm_fault *vmf) mapping_locked = true; } } else { + ret = filemap_fault_recheck_pte(vmf); + if (unlikely(ret)) + return ret; + /* No page in the page cache at all */ count_vm_event(PGMAJFAULT); count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);