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 0576EC77B7A for ; Thu, 18 May 2023 03:36:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEA66900003; Wed, 17 May 2023 23:36:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9AC8900004; Wed, 17 May 2023 23:36:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6BC7900003; Wed, 17 May 2023 23:36:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A0576900003 for ; Wed, 17 May 2023 23:36:05 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 594C41A0482 for ; Thu, 18 May 2023 03:36:05 +0000 (UTC) X-FDA: 80801962290.13.94F78D6 Received: from out-10.mta0.migadu.com (out-10.mta0.migadu.com [91.218.175.10]) by imf10.hostedemail.com (Postfix) with ESMTP id 5E36DC0010 for ; Thu, 18 May 2023 03:36:03 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kYDZkSKo; spf=pass (imf10.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.10 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684380963; 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=R/xSxkO34rTHB5jgYq+EIG5zjckP6E+hsO+vx3uRhUA=; b=GRvODLnb2nR3qptVpW7Xr0ON8H2QNwOmbRLdjdBLboafnZx6WhQDx5RQt14uphhUGZn5x9 uwQAiyE3nPV/dgWVd4iOTpZwJpeLqXQX849xF6xhig3EA5oMbz7zA7t6rJaAQW9BQyAb7r rgc7e5nUD10ADYnFWOzvUCyRXLZe1e8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684380963; a=rsa-sha256; cv=none; b=QmcVQ1VghjXLF0JJZWR8k8r4QV+kUzlaQxuQIu9nWE23edQSnPDuEvCa5kJuBRRaN8dHCr KfafLXBGCZz13pgzp7RqkWdzQcg9gC7Ga1doTUJnzA85eC9THuetizTO5VW+jfDHYL6E0U i75nQIczTnpg5JXGtG+0JPov2amTJ0A= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=kYDZkSKo; spf=pass (imf10.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.10 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 17 May 2023 23:35:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1684380961; 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: in-reply-to:in-reply-to:references:references; bh=R/xSxkO34rTHB5jgYq+EIG5zjckP6E+hsO+vx3uRhUA=; b=kYDZkSKo3Vd+Vlz3v1TqKnv5UZZxWD+B7u0uWz6Dkfqr9ZyJBFtS6MByThfEB+n4utJGLM rNGCmqvF4gzQQHhf299ssyn7P7e2uN7wJt5+ZNmfgQshSe4hzV+RJ++vjONiskQT+QYUZt XF9WSVQIfHOOCRmlRkgYsI2hqFoVZfo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Mike Rapoport Cc: linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Song Liu , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() Message-ID: References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230308094106.227365-2-rppt@kernel.org> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 5E36DC0010 X-Stat-Signature: zs98pi9nrp1bex1zqa7nasfj6adkp89k X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684380963-324319 X-HE-Meta: U2FsdGVkX19rcMT5z8Y9WJkdK0cvDmddG87XxvPuXxuMJ8R4rtgMYNSahNRH8osGs2rdzMzVFvJX/sc2Df461xMyZeA6yZlkJiQPtHP2Aokz390xMuEUWB0jYAZQCohEUzsvSOEP+5pmvdxF0e04eN7GQN7MYw6YinaLXiG+xifkZAbumxNhZgwV8qocmaUN8C7pXD5CEoUqLLuGsGHbHkTo/PrzYGs7DLL0PvGEstsFjfmwfm0Zx4S0E+HsiTog6+XpHwYFoE3K8rxKFZhr7jTAGcLag/jONlcsw9EXx3eQo/Un7qY2PzcHe/B0yQIl5r8VJzo79ej5AhAf7jx+YUvsnBjroC5AwPDLIKTKGv1S7WS/Gr6IGJ2MPlLj0aBJOVk0Rfw5rRfEYeSvNtwqSxc2qSYbotEwrZti4tRP1+i3dIQEGulBBGCFvuM23oF/zCtrzOGEYMgCsE4yN2LlmCjwxRqXV5Jb4Od7aZ6/18gRYky/MIypzviqvim2RUMosG0b63Lgd9Na41Ew4A02DVg+OZ4eTJC1S+KxU6awgqOtecdHkP3kDG0ShOPAaaGbf5UXtVgq4qhz321mFqH/R8VI/oj5sutV7mL/jlP7OON/eiIDLo5SBamWJtetv+YArdVzYULvp6fFkNlLN4Lt+a+KnvNYc4RvoHOhLGSug/pMsEv3B9S0gJF+NaeMyxb+AIm+w0358+w2+D5pKy/fzmS16DgyYRpMsveS++UI85ATrrQuPlI0IXLWbtD4CQCmwj1zFSqFXq3Fp7L6HSgJSWSsrnjmRinLkUE746VLjdn0RaikUQkU0C+L1He+nQZ0KSfVCTcIxyz1EzdKQZKCbExRX3BS1QeViWknhZ5MuU05oH2s6GjSV7/v5bDBMRZdiwMD3C2M/xqpL4xDSSKS4e9ZNHzk9jxbl4PytSuCzRhEMkTjVZP3JxbCykXgRBTmsPjC1oF2KiwJoFxNVml ZE5HAvtT 2T9jqCCNq/BXhrDnkNeKqcI6cFz0a8mhyD6zkj3c1lMZ9ff5gIbKnHLwOnBUCDM0ZRt6EKNJqnL7gUMqDrjYJ46Q08ioXIUKDSPKDi0jNMRO7akWPf3XI7Ncye8OGsNR/w3M6goAPaTOWE9shCirGFhFgbBLq4D25Gf9F 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 Wed, Mar 08, 2023 at 11:41:02AM +0200, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > When set_memory or set_direct_map APIs used to change attribute or > permissions for chunks of several pages, the large PMD that maps these > pages in the direct map must be split. Fragmenting the direct map in such > manner causes TLB pressure and, eventually, performance degradation. > > To avoid excessive direct map fragmentation, add ability to allocate > "unmapped" pages with __GFP_UNMAPPED flag that will cause removal of the > allocated pages from the direct map and use a cache of the unmapped pages. > > This cache is replenished with higher order pages with preference for > PMD_SIZE pages when possible so that there will be fewer splits of large > pages in the direct map. > > The cache is implemented as a buddy allocator, so it can serve high order > allocations of unmapped pages. So I'm late to this discussion, I stumbled in because of my own run in with executable memory allocation. I understand that post LSF this patchset seems to not be going anywhere, but OTOH there's also been a desire for better executable memory allocation; as noted by tglx and elsewhere, there _is_ a definite performance impact on page size with kernel text - I've seen numbers in the multiple single digit percentage range in the past. This patchset does seem to me to be roughly the right approach for that, and coupled with the slab allocator for sub-page sized allocations it seems there's the potential for getting a nice interface that spans the full range of allocation sizes, from small bpf/trampoline allocations up to modules. Is this patchset worth reviving/continuing with? Was it really just the needed module refactoring that was the blocker?