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 D453DC83F10 for ; Sun, 27 Aug 2023 11:50:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 161F7280001; Sun, 27 Aug 2023 07:50:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EBDF8E0001; Sun, 27 Aug 2023 07:50:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECF3E280001; Sun, 27 Aug 2023 07:50:42 -0400 (EDT) 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 DD36F8E0001 for ; Sun, 27 Aug 2023 07:50:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 61C021601E9 for ; Sun, 27 Aug 2023 11:50:42 +0000 (UTC) X-FDA: 81169717524.22.C21C7DC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 45460100029 for ; Sun, 27 Aug 2023 11:50:40 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="tQClh/kg"; dmarc=none; spf=none (imf14.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=1693137040; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6AZBdh/XEDaA5kGBJST50i9hlDPyoWJs0bfL8AH3skI=; b=Q/bFpq2itkLa5hiIAWCC6OX/HbQvvBbkIEKyb9cNdibPpNxVEwmn9ygDDSIRinJ7sfqlo7 WVUM98jnW4gT4H2PMzzLbrArMH7IUVBVpADjQ8Q1fmtMPdxHFgMKoFrkTmcnyPBF/SPxjc Kt210UfOZZv7G/aFkTKwzrpoOZXuAAA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="tQClh/kg"; dmarc=none; spf=none (imf14.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=1693137040; a=rsa-sha256; cv=none; b=ePq1vSa0eYwjk55vLuNidIEA0m9GKgVPtzYdshAoZrrXEmhRliIQjpFru+cqgzsmq5RzCE X/fSqkszG3V9ncUAVFjA7/pU4flJHGTrGPkwfTTuYDcVHuu7/AB41MxaK0OreeKafoJdLC yo+8cJHTKGkYloTj62nT0Q+c0aGknkM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6AZBdh/XEDaA5kGBJST50i9hlDPyoWJs0bfL8AH3skI=; b=tQClh/kgCfLePckoa3SHirtrku eMUZbfMPiFVC+jI00sELBWt2jmlDmtdF7FQr9h070OvviYn/TNGJsN8iX7L9MvKdQqZYJj/EQkHxd qFbBBdy82TS+f7T77VpRK12Z0Bj7EVxt35Y/4/9pMHxPKxKfbEGN2sxuXeESMYf08XSzJRcpWrmLn BjbtEBvSVbB/jv6vf1JjDVm0r1MZX56YBqrhxfo1UTpDWytdnkalnBu7sJabNvJUCbgWRlIUik5Ba C/nArOEUzfi3ub60QcLQAx2m8OKpfMxUKXXXKseZ5F68wfwa6Um3XGH3l3hz0zZasw2aGS1N2uK+M 8lghF+pA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qaEHr-00BS80-El; Sun, 27 Aug 2023 11:50:35 +0000 Date: Sun, 27 Aug 2023 12:50:35 +0100 From: Matthew Wilcox To: Lorenzo Stoakes Cc: linux-mm@kvack.org, linux-perf-users@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, urezki@gmail.com, hch@infradead.org Subject: Re: [RFC PATCH 4/4] perf: Use folios for the aux ringbuffer & pagefault path Message-ID: References: <20230821202016.2910321-1-willy@infradead.org> <20230821202016.2910321-5-willy@infradead.org> <5231893a-e5a5-4544-a6d2-2c98cbebca09@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5231893a-e5a5-4544-a6d2-2c98cbebca09@lucifer.local> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 45460100029 X-Stat-Signature: g3arh15zx1sjdnt96un7n7tmondfo6xz X-HE-Tag: 1693137040-472651 X-HE-Meta: U2FsdGVkX1+vY8W3ZQgmrqkw0hx9+Q/Yxz1yC3A6LBp5bSpbrAdhpfc76x9aoy5hW4Gafw0R9bCTWcaBgcwXgyyHp1ZtWGkA5sKNLYIDqTCRX1beYPdfoRxJcaLHDc3G18e6HEYKo5Sh+CmE3M9Qvx0ktu4QUe0LhHM0mjkLslfe6nlHj++IVW8DscFfmsO/thx2oncvTwqRTdUUN1USSJzKwLHiOMHL4rrROHERlSDW/YPh9AUfrSM9u5RfYCfyDvSi2IN6YoI3Cal7+xTlbVEFadHAIVCSNi9MvPhUVVdZd73FGNL6nm+XhPeob4RwyzNZ6590SCYPuRK7qT+hNpb8YfTTNdESMbvJrPKoViZ10Qu2KtGgrCI5mU8SIXMpz4ExyA9L9vD6e7e3fICU6AQ2zw4/+TP1yXDdX0WHTREVRqW8Oz7uLBrzbtKYS5FPQIGDPhhgvHcHh1WQhIeE7vWtljBQbLi5iIysV/iH2jEoARFIgFK6ps2A6PvZJfi168HbjqMtm3YakSAaRExLN7E+NzjHvvuzGxoEv2Q8vqTqfF1wPvG/CyXViHc14L8p7IvD2Mo6J61caNfKmYcBxqkelo0EXInwS9GOPQ+BpDnPC507ohtHSka0tacalHIToAUMqaqnQCwY/YJlASnM8g5H9uv+bV6UG4pdETqcuaDqsS3tDIw+OaTCuADYzr+BqxuFv91YC1SaeFqa8w3l4QdjsZoNecSvXLs5hoyN/wjg0E2GRUGwJFjWx10rp/hgU7TlSieD/4ck2sarkHowQoC+i3Ha/lgqq2AIN2ddTzF/w+RPM29IJRrXb1e7SvdTWc94cbzRJFzWbM8aBNV29QrYTmTXDVuYAaDuhuJ/HlIL4+EGrKsiB1Sd7EMLb1/Va48ugVtjz98auMMZJuXfxxIwZhUxw7FMQaWhzEl4MBXPG7bowmhXkK9RrlWmBeYfsazFbsH7ZsJAZdZo1n+ j5oaM4MZ ToWJdRLkT8fMSBbu30z/YKy8C52jjTrA3x+ae5swIXoVaiTtXslOYwvHQ8R5w9jdSkFAm99LRE5yHcMkDo/btvx/RukE16pxvBL+F8Yj0Foool/TyWWVhhshNz81KBe1pQdmR99SU7W5Mkrw= 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: On Sun, Aug 27, 2023 at 09:01:04AM +0100, Lorenzo Stoakes wrote: > On Mon, Aug 21, 2023 at 09:20:16PM +0100, Matthew Wilcox (Oracle) wrote: > > - if (page && order) { > > - /* > > - * Communicate the allocation size to the driver: > > - * if we managed to secure a high-order allocation, > > - * set its first page's private to this order; > > - * !PagePrivate(page) means it's just a normal page. > > - */ > > - split_page(page, order); > > - SetPagePrivate(page); > > - set_page_private(page, order); > > I'm guessing this was used in conjunction with the page_private() logic > that existed below and can simply be discarded now? As far as I can tell, yes. > > - } > > + folio = __folio_alloc_node(PERF_AUX_GFP, order, node); > > + } while (!folio && order--); > > > > - return page; > > + if (order) > > + folio_ref_add(folio, (1 << order) - 1); > > Can't order go to -1 if we continue to fail to allocate a folio? Hm, yes. > > @@ -707,17 +696,21 @@ int rb_alloc_aux(struct perf_buffer *rb, struct perf_event *event, > > > > rb->free_aux = event->pmu->free_aux; > > for (rb->aux_nr_pages = 0; rb->aux_nr_pages < nr_pages;) { > > - struct page *page; > > - int last, order; > > + struct folio *folio; > > + unsigned int i, nr, order; > > + void *addr; > > > > order = min(max_order, ilog2(nr_pages - rb->aux_nr_pages)); > > - page = rb_alloc_aux_page(node, order); > > - if (!page) > > + folio = rb_alloc_aux_folio(node, order); > > + if (!folio) > > goto out; > > + addr = folio_address(folio); > > + nr = folio_nr_pages(folio); > > I was going to raise the unspeakably annoying nit about this function returning > a long, but then that made me wonder why, given folio->_folio_nr_pages is an > unsigned int folio_nr_pages() returns a long in the first instance? Futureproofing the API. While I don't expect us to be allocating order-32 folios any time soon, and x86 has excluded p4d-sizes from the architecture, I don't want to have to go through and audit everywhere when it turns out we do want to support such a thing on some architecture. (on x86 PMD - order 9, PUD - order 18, P4D - order 27, so we'd need a hypothetical P5D level, or a machine with, say 16k pages, which would go PMD-11, PUD-22, P4D-33, and be managing a folio of size 2^57 bytes) But supporting nr_pages stored directly in the otherwise wasted space in the folio seemed like a cheap win, and there was no reason to take up the extra 32 bits. Anyway, here, we know we're not getting back an arbitrary folio that somebody else allocated, we're allocating for ourselves, and we know we're allocating something rather smaller than that, so it's fine to calculate in terms of unsigned int. If I were writing in rust, I'd use usize, but since nobody's done the work to make rust types available in C yet, I haven't done that either. We actually use usize as a variable name in a couple of hundred places, so turning it into a generally available type is harder than one might like.