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 BA3F6EE49A8 for ; Mon, 21 Aug 2023 20:20:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15C4F94000F; Mon, 21 Aug 2023 16:20:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1120494000D; Mon, 21 Aug 2023 16:20:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D414794000F; Mon, 21 Aug 2023 16:20:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BBD9394000D for ; Mon, 21 Aug 2023 16:20:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8E364140CDC for ; Mon, 21 Aug 2023 20:20:29 +0000 (UTC) X-FDA: 81149229378.02.5CA2FA2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id B40D2100019 for ; Mon, 21 Aug 2023 20:20:27 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rgdV2c35; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692649227; 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:references:dkim-signature; bh=/Guyl86RjRFKgVcvJ+J4vVv/rAafEsDNvMt8mUITwhs=; b=gzJ1RqdBeewDzMaakTlY3b5UNhrWu0C+DjzY2O0GoSwKXAMCyxvd/H2On8WFuXFNqJRqnX br9RVtPCBIWQuMJdArZGCegQpWwrhzYDnaUsw5//DDjTFZ8k4BI9YFkvidGjtfo2wXhwBx yAxS/vJu5NVh9v6fkhwCD6zIvXRgaEk= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=rgdV2c35; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692649227; a=rsa-sha256; cv=none; b=tNiSTQlZYovYu/DNUrj0KEG1ZF4juPve0EA3zPPBcToYs2tKAl6kd+XwzEF/mBayUch5EY gSuH26W3LAvnmKcVCyvUM0g/nhX7NxTrothcmNsDdBkb7EILbjtzlsOkp7Z8jnp2xAxdKR vTiOrty3xFgf2n3U9bng37UHdpEHdNY= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:MIME-Version: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:In-Reply-To:References; bh=/Guyl86RjRFKgVcvJ+J4vVv/rAafEsDNvMt8mUITwhs=; b=rgdV2c35jokG8Kq8cBzPW6Badf IPpSevMrDXHyezbLEhmgoPqUcCrAGcVqKPvJjqVtjAaLmsZUvZqUwuguW9K4DGpDXcoJKtY9drWa6 Z4Z+SQP1Dj22lnJXivbTGYnhkb+AZJKIokbFdHdH3Q2t1KBQiaFofXJVuNeELP7vvXepp3NVUg/mJ SQTjbrLOZ3X+NoP1DnIZ5fK5f2Fxd2Kx6YMnS5IuYkVCbhlwW3rooXuW6qZj8n063ePXedXLZT0Kj 5w9iHZRH12gqkG+MooSHrwofO3XXJlPfLUgHs0kcpFy5YUtXtrbSwK/NlRQxl7w+28dlIbR5MuRx3 W0AjylSA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qYBNq-00CD6s-3K; Mon, 21 Aug 2023 20:20:18 +0000 From: "Matthew Wilcox (Oracle)" To: linux-mm@kvack.org Cc: "Matthew Wilcox (Oracle)" , linux-perf-users@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com Subject: [RFC PATCH 0/4] Convert perf ringbuffer to folios Date: Mon, 21 Aug 2023 21:20:12 +0100 Message-Id: <20230821202016.2910321-1-willy@infradead.org> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B40D2100019 X-Stat-Signature: adsw3qx1uqoja8zo76tsen1dctz6y7ut X-HE-Tag: 1692649227-126411 X-HE-Meta: U2FsdGVkX1+V4Qb5GY0HyNptCwoOyRfTroDKZ8wFZiFue3LakW940xynuqM6UkRFXG8XUarGTodDPaRAdTioTnjX1tXaqYoEFeeKSDlLOM9JCI0cIVnrx8dpRIcXq0Op7cFOcHFj5tgjTYab1DQOnP8SdYuCOpuNp1di6hth+qrw2EfPk2it9FXKLGIfcRNZirjjNrONE//fukhWZwPYN8X643JVWFpz+IQ2ld/pRng3LpIftLjzsW2B1wnGIX4SO7F4M45DliEGRA6Sz2S4+mpfRJJsX9fhijf1AaijCx+SyDYcy2QEpzd4vl6jEATF1xQ/qDFaTrJu59LJFq+T3lbwjtIpXuZlrPxRbs3axFLDmaZK9Hpb1eUxEx8cAGN2SAUW/LZttTc5vRJdBzxlwfD46+ySyTv1gDbXn5bcf+4RmLNZGmNK2KYB1P3RX/yDet/GbKJN477sr0Dk2bKTQ2cOQq/QANEkjXzc/q63jVH96AxIv7FqyR6OiF8HXM82fLZsWPr5DNIb0wFRezMPuhkbB60aeo/H6yZgA1Ji6JUkIs1ELGwNSjXd/cpH87be+WveTYFXpymRvX62hrQjZ4BiWycneYWH6liqLYe+vzJYZqTiFohRw+86pBYVB/0ycNqI/bDkMjFeQbhPSy9785i6rrgxDNU9y+TMeuEyFbFMVnxAv4mWxVaFaMyJ58GG8YJG5zj6kkMedm/0WdrfW9M/IwoLZq/zLCtLmKkoMUDVxEVn/q9EU0RUS8ex0Epp/k43ekygMrQtEN8sJRm6t0mZ5tfU/MQRUQjzErvIUVYhxeWanmLMpbifMcV+0Gz+whdwPKajh2lrGN3opGU761QvcQzLfUsElt37TL3TrjJC+5vXVb2pqH/yXob5TYTUAT8GWFHfP17Izmigzcpoz7L/CyTd//oODBjyEFqWW0qlJ2huDuFaCCKnFVSB5HtiKOub7Ut0Y4fQcpb1hyj ertE4XS7 JdqJldrRibi4Zz0nb5ZGtAOVTaszQXNpY5bid7lkD1fJQiPju1ZoX780lO20ie/Y44QTgl4wZYkZSEnmgNsYS48ERxCWpJRPrzaH46baYOrw8usdpstOETmGxYA== 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: The motivation here is to remove uses of page->mapping as part of the quest to shrink struct page. I'm unsure about some of this as the perf ringbuffers present some new challenges that we haven't faced before. Perf has three different ways of allocating memory for the ring buffer. There's an individual pages way, a vmalloc way and a physically contiguous way (for the aux buffers). The fault handler can map all three. The fault handler can map the _first_ page read-write, but all subsequent pages are mapped read-only. That makes calling vm_insert_page() not feasible; that would allow all pages to be mapped read-write (yes?) So the fault handler sets vmf->page and returns, in order to let finish_fault() set it up. I'm not really sure why page/folio->mapping needs to be set by the fault handler. What goes wrong if we leave it as NULL? Likewise, do we really need to set ->index? I've taken that out for now, but maybe that'll make something fail (perhaps an rmap walk? Do we really need to do rmap walks on device driver mappings?) I don't like drivers playing these games with pages/folios. I think we need better support for these kinds of things. Probably in the form of helpers, given how unusual some of perf's requirements are. More broadly, we don't have a detailed plan for how vmalloc memory gets handled in a memdesc world. For the vast majority of vmalloc allocations, the pages allocated need no descriptor; they're only accessed through the virtual address by the CPU. This is a case where we need to mmap the vmalloc memory. There are also cases where we need to do I/O to vmalloc memory; we need to understand what fields from struct page are really needed for each of these two requirements. Matthew Wilcox (Oracle) (4): perf: Convert perf_mmap_(alloc,free)_page to folios mm: Add vmalloc_user_node() perf: Use vmalloc_to_folio() perf: Use folios for the aux ringbuffer & pagefault path include/linux/mm.h | 5 +++ include/linux/vmalloc.h | 17 +++++++- kernel/events/core.c | 13 ++++-- kernel/events/ring_buffer.c | 83 +++++++++++++++++-------------------- mm/vmalloc.c | 9 ++-- 5 files changed, 72 insertions(+), 55 deletions(-) -- 2.40.1