From patchwork Tue Dec 19 07:55:25 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 18281 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp1778148dyi; Mon, 18 Dec 2023 23:56:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IE0sFa0GKfio9OSG6ACZEVgk+Z81U9+hwv15vlC+JevKKy3TEVA3Hfz4tApOgw6Vsv5D7Dl X-Received: by 2002:a17:902:eac5:b0:1d3:9ad2:6455 with SMTP id p5-20020a170902eac500b001d39ad26455mr5441014pld.97.1702972576826; Mon, 18 Dec 2023 23:56:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702972576; cv=none; d=google.com; s=arc-20160816; b=yQMPgOTnAEPjlHjnwDo6Ac6/4P8eup/31kFhIm9g1qwCCuROy5kxRrmwMIbR8ukcFe pnROhad1LVZr5LSaT5b5HYJPoEThetRvLeFSQBizQZ4W1uFFNCrPlVBsdXLbOW0znll+ N3FuUggCXUyv+UUsWUaCaeJA+1hcS02QWFjkpo6jTjeCsOt10J07xq1wIMnbpzFO7DOR dFrwYXkXYCWmV0AM3jl4PFsjU9fTd27Vbm+ZuP4GgZHmRZuuynMBe1WwE6zdUz2slELY mYE2x0Z8cF10/zv43sdAk/63kfR9RvN6VpViM20G7UWu0scmjv26IiZe06fQSsWZl9IL FZmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=+h83lLyn/5apLRr4X1Iml0TGvxqR5/pwpG6+wMVRoO8=; fh=3mpu6Yyr5hMzDKtkQvzcApl7ZSQGU4G8QyIY2BAU7VY=; b=yh3ybElF7FoX0Ky3nJRqZc19Eg6A9THPFNZSXpdecywPMB1Apv8EPTF/vmw5ggN0kR JeWqW5+K0kwmO12K4fZAmNF1Zc9c/Av1Oru++mVf4IoyMwohYj9TCUhe5HYnSfqYHc54 DdJFfmjKUQmX45HMm06k2dzsPN+7exrfBZPAOsOnBezUTLh25MdJGudtAfcXlhIUOrJF 7ebFT09+2pAu/Ti8W9eAj9o5H9OSWuW6KbQDnyIoQWXQ4fhf/Js43cwtoicEULFpPIhu Id8zrRtBuU8O3DzNUZswATSha6cSytvagbnztzIxEN+RoORZkseg5uPQzwlnI1JS/vyy C/XQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XR8GUsal; spf=pass (google.com: domain of linux-kernel+bounces-4833-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4833-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id i9-20020a170902eb4900b001d3ac97bc75si3889401pli.455.2023.12.18.23.56.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 23:56:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4833-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XR8GUsal; spf=pass (google.com: domain of linux-kernel+bounces-4833-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4833-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 936B2286921 for ; Tue, 19 Dec 2023 07:56:16 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 21636125B2; Tue, 19 Dec 2023 07:56:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XR8GUsal" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9120411712 for ; Tue, 19 Dec 2023 07:55:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702972556; h=from:from: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; bh=+h83lLyn/5apLRr4X1Iml0TGvxqR5/pwpG6+wMVRoO8=; b=XR8GUsaluDchgruKmarqBEqjW3Wqmhwn4GplqLYMVIMv0CFAKTWmyjaZJ4QLKt6Y03shFw 5SPz1ofzy3xk0tM53bvNAgaXdpVWJxzfVMba7MLpXt7SgdL9i/0dCMaKKz9fVEpw8TaBHi XD0l0+6cK3iff/FxWtQuYwIL0K3Oa2w= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-460-78fty2BGN2uAAfrfPZNG0g-1; Tue, 19 Dec 2023 02:55:53 -0500 X-MC-Unique: 78fty2BGN2uAAfrfPZNG0g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 065E63C025C1; Tue, 19 Dec 2023 07:55:52 +0000 (UTC) Received: from x1n.redhat.com (unknown [10.72.116.117]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83B262026D66; Tue, 19 Dec 2023 07:55:40 +0000 (UTC) From: peterx@redhat.com To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Matthew Wilcox , Christophe Leroy , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , Mike Kravetz , Mike Rapoport , Christoph Hellwig , John Hubbard , Andrew Jones , linux-arm-kernel@lists.infradead.org, Michael Ellerman , "Kirill A . Shutemov" , linuxppc-dev@lists.ozlabs.org, Rik van Riel , linux-riscv@lists.infradead.org, Yang Shi , James Houghton , "Aneesh Kumar K . V" , Andrew Morton , Jason Gunthorpe , Andrea Arcangeli , peterx@redhat.com, Axel Rasmussen Subject: [PATCH 00/13] mm/gup: Unify hugetlb, part 2 Date: Tue, 19 Dec 2023 15:55:25 +0800 Message-ID: <20231219075538.414708-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785696172847118263 X-GMAIL-MSGID: 1785696172847118263 From: Peter Xu This is v1 of the series. The series removes the hugetlb slow gup path after a previous refactor work [1], so that slow gup now uses the exact same path to handle all kinds of memory including hugetlb. It's based on latest mm-unstalbe (c13bdc82ada9). RFC->v1 (use old verion's patch index): - Fix build for !THP and/or !HUGETLB - Fix a bug in the hugepd path that can cause a loop - patch 3: - Rename to "Make HPAGE_PXD_* macros visible even if !THP" [Christoph, MikeR] - patch 5: - Posted separately as a devmap bugfix - patch 6: - Add a comment above gup_huge_pd() explaining the file folio writeback issue, with references when anyone would extend hugepd to other types of file memories [Christoph] - patch 7: - Keep parameter name as "page" in record_subpages(), modify the commit message by removing any assumption on head page. [Matthew] - patch 12: - Rename to: "mm/gup: handle hugetlb in the generic follow_page_mask code" [Christoph] - Added patch: - "mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES", this helps to fix build for !THP and/or !HUGETLB - Added patch - "mm/gup: Cache *pudp in follow_pud_mask()", as suggested by Christoph For the long term, this is one small step towards merging hugetlb specific codes into generic mm paths. From that POV, this series removes one reference to huge_pte_offset() out of many others. To make it work, the generic code will need to at least understand hugepd, which is already done like so in fast-gup. Fortunately it seems that's the only major thing I need to teach slow GUP to share the common path for now besides normal huge PxD entries. Non-gup can be more challenging, but that's a question for later. There's one major difference for slow-gup on cont_pte / cont_pmd handling, currently supported on three architectures (aarch64, riscv, ppc). Before the series, slow gup will be able to recognize cont entries with the help of huge_pte_offset(). Now it's gone but still working, by looking up pgtable entries one by one. It's not ideal, but hopefully this change should not affect yet on major workloads. There's some more information in the commit message of the last patch. If this would be a concern, we can consider teaching slow gup to recognize cont pte/pmd entries, and that should recover the lost performance. But I doubt its necessity for now, so I kept it as simple as it can be. Test Done ========= This v1 went through the normal GUP smoke tests over different memory types on archs (using VM instances): x86_64, aarch64, ppc64le. For aarch64, tested over 64KB cont_pte huge pages. For ppc64le, tested over 16MB hugepd entries (Power8 hash MMU on 4K base page size). Patch layout ============= Patch 1-7: Preparation works, or cleanups in relevant code paths Patch 8-12: Teach slow gup with all kinds of huge entries (pXd, hugepd) Patch 13: Drop hugetlb_follow_page_mask() More information can be found in the commit messages of each patch. Any comment will be welcomed. Thanks. [1] https://lore.kernel.org/all/20230628215310.73782-1-peterx@redhat.com Peter Xu (13): mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES mm/hugetlb: Declare hugetlbfs_pagecache_present() non-static mm: Provide generic pmd_thp_or_huge() mm: Make HPAGE_PXD_* macros even if !THP mm: Introduce vma_pgtable_walk_{begin|end}() mm/gup: Drop folio_fast_pin_allowed() in hugepd processing mm/gup: Refactor record_subpages() to find 1st small page mm/gup: Handle hugetlb for no_page_table() mm/gup: Cache *pudp in follow_pud_mask() mm/gup: Handle huge pud for follow_pud_mask() mm/gup: Handle huge pmd for follow_pmd_mask() mm/gup: Handle hugepd for follow_page() mm/gup: Handle hugetlb in the generic follow_page_mask code include/linux/huge_mm.h | 25 +-- include/linux/hugetlb.h | 16 +- include/linux/mm.h | 3 + include/linux/pgtable.h | 4 + mm/Kconfig | 3 + mm/gup.c | 362 ++++++++++++++++++++++++++++++++-------- mm/huge_memory.c | 133 +-------------- mm/hugetlb.c | 75 +-------- mm/internal.h | 7 +- mm/memory.c | 12 ++ 10 files changed, 342 insertions(+), 298 deletions(-)