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 A16DEC4167B for ; Mon, 7 Nov 2022 17:26:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0447B6B0073; Mon, 7 Nov 2022 12:26:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F36EF6B0075; Mon, 7 Nov 2022 12:26:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFE3E8E0001; Mon, 7 Nov 2022 12:26:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CCB9F6B0073 for ; Mon, 7 Nov 2022 12:26:55 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9F5DA1205B0 for ; Mon, 7 Nov 2022 17:26:55 +0000 (UTC) X-FDA: 80107326390.21.343726A Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf26.hostedemail.com (Postfix) with ESMTP id E4E1414000B for ; Mon, 7 Nov 2022 17:26:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aLI+4wjhcQmAlu+Gn5bISv4vWpUWkAnzhvT5WsWZyPs=; b=IeEGQ3fgr586+CYhOV5y4IFBIJ XPxBM0Rca6JHVxak18bq7Ml6Iuka7K+DnJAgjwKXOo0DuoqusIDphybfKTbjtu0/rBoFssTe3ZZ2S N/mJXOm84q7sowtj3hyqyVCd6m3uFoHVXir4YfmS+62wFYSmqYi/o2pahmUFameYyv5khNmOcbask nDpYm04ePoq4ipkiw4mxt1HVSwvYmJCFszbAwHeLLKB+p96K2Qs6jNFlLqkuy8FmBiXxR7V2oePgf lnQAfejAYSEOMKv+BsKnkrv0Twi93RQC98noKKIhMBaIoGy5QgmeD27AZVSal8dJ8uIe9Yj9TnfoJ CLDbGYLQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1os5tT-00GfW6-NJ; Mon, 07 Nov 2022 17:26:43 +0000 Date: Mon, 7 Nov 2022 09:26:43 -0800 From: Luis Chamberlain To: Mike Rapoport Cc: Song Liu , bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org, peterz@infradead.org, hch@lst.de, rick.p.edgecombe@intel.com, dave.hansen@intel.com, zhengjun.xing@linux.intel.com, kbusch@kernel.org, p.raghav@samsung.com, dave@stgolabs.net, vbabka@suse.cz, mgorman@suse.de, willy@infradead.org, torvalds@linux-foundation.org, a.manzanares@samsung.com Subject: Re: [PATCH bpf-next v1 RESEND 1/5] vmalloc: introduce vmalloc_exec, vfree_exec, and vcopy_exec Message-ID: References: <20221031222541.1773452-1-song@kernel.org> <20221031222541.1773452-2-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=IeEGQ3fg; spf=none (imf26.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667842013; a=rsa-sha256; cv=none; b=7vqwrlxMA9NGiAuMFHDpIIzP1EaLasfqdt4Xnh7iE90RsbxyN+85l7jXCs9bvZyL5eL2Nd CvPdsxwX8FKyyec7Cqj8WQDsAst1yyheqZeVjulqsA2EItbLNLNQtq3dPb2JmvBVSjCLwK WvKPHsLHwaF9BjC3FPm5zc0PsL6Hpa8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667842013; h=from:from:sender: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=aLI+4wjhcQmAlu+Gn5bISv4vWpUWkAnzhvT5WsWZyPs=; b=qKOGAKhSucfjY+EZBH82+n9XGoTIaoNC7y19gjms5ZtjKe9P/AsyWgR7c2cRILGPkWSXt8 82iXII1R7yM30A8tem8ykzIOnfna/ktwVYSkk2snL8z+jUreSe/h0susa+GY+tGUpL6wOo SmfIAQgOAO0FOcTLmFEseDzj7fWfGKM= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E4E1414000B Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=IeEGQ3fg; spf=none (imf26.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Stat-Signature: ph74w6pd5mx3fiqwk9e9t7nxei9matnd X-Rspam-User: X-HE-Tag: 1667842010-448885 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 Mon, Nov 07, 2022 at 08:58:17AM +0200, Mike Rapoport wrote: > On Thu, Nov 03, 2022 at 11:59:48AM -0700, Luis Chamberlain wrote: > > On Thu, Nov 03, 2022 at 05:51:57PM +0200, Mike Rapoport wrote: > > > > > I had to put this project on a backburner for $VARIOUS_REASONS, but I still > > > think that we need a generic allocator for memory with non-default > > > permissions in the direct map and that code allocation should build on that > > > allocator. > > > > It seems this generalization of the bpf prog pack to possibly be used > > for modules / kprobes / ftrace is a small step in that direction. > > > > > All that said, the direct map fragmentation problem is currently relevant > > > only to x86 because it's the only architecture that supports splitting of > > > the large pages in the direct map. > > > > I was thinking even more long term too, using this as a proof of concept. If > > this practice in general helps with fragmentation, could it be used for > > experimetnation with compound pages later, as a way to reduce possible > > fragmentation. > > As Rick already mentioned, these patches help with the direct map > fragmentation only indirectly. With these patches memory is freed in > PMD_SIZE chunks and this makes the changes to the direct map in > vm_remove_mappings() to happen in in PMD_SIZE units and this is pretty much > the only effect of this series on the direct map layout. I understand that is what *this* series does. I was wondering is similar scheme may be useful to study to see if it helps with aggregating say something like 32 x 64 kb for compound page allocations of order 16 (64 Kib) to see if it may help with possible fragmentation concerns for that world where that may be useful in the future (completely unrelated to page permissions). > A bit unrelated, but I'm wondering now if we want to have the direct map > alias of the pages allocated for code also to be read-only... > > > > Whenever a large page in the direct map is split, all > > > kernel accesses via the direct map will use small pages which requires > > > dealing with 512 page table entries instead of one for 2M range. > > > > > > Since small pages in the direct map are never collapsed back to large > > > pages, long living system that heavily uses eBPF programs will have its > > > direct map severely fragmented, higher TLB miss rate and worse overall > > > performance. > > > > Shouldn't compaction help with those situations? > > Compaction helps to reduce fragmentation of the physical memory, it tries > to bring free physical pages next to each other to create large contiguous > chunks, but it does not change the virtual addresses the users of the > underlying data see. Sorry I understood that 'bpf prog pack' only only used *one* 2 MiB huge page for *all* eBPF JIT programs, and so the fragmentation issue prior to 'bpf prog pack' I thought was the fact that as eBPF programs are still alive, we have fragmentation. In the world without 'bpf prog pack' I thought no huge pages were used. > Changing permissions of a small page in the direct map causes > "discontinuity" in the virtual space. E.g. if we have 2M mapped RW with a > single PMD changing several page in the middle of those 2M to R+X will > require to remap that range with 512 PTEs. Makes sense, thanks. Luis