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 F2BCAC352A1 for ; Sat, 3 Dec 2022 14:46:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C2826B0072; Sat, 3 Dec 2022 09:46:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 073326B0073; Sat, 3 Dec 2022 09:46:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E55C36B0074; Sat, 3 Dec 2022 09:46:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D31D06B0072 for ; Sat, 3 Dec 2022 09:46:33 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8991AC0AC8 for ; Sat, 3 Dec 2022 14:46:33 +0000 (UTC) X-FDA: 80201271066.13.B7A83E1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id 1552DC000C for ; Sat, 3 Dec 2022 14:46:32 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QbV4kHKp; spf=pass (imf28.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670078793; 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=dUay3YvAItAViHu3bl5nHkMVFzMySJphB9M6JzNLlrI=; b=jTBPOrSlSX7ULbM/var87Sd0HQODuOLp0F8WdLEyj6r47Wo1CCHF4FEcaCnYX6SSvjE1+D OMyHGAjKFqqTWcZ09jCnauEjKJAl5oh8QjVo4CugWxUPEJjiu+TjRWp8nOtKB8BpCDYvPx nGGkcPG50Jv718XQ8XG1RrFwcXCwrqQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QbV4kHKp; spf=pass (imf28.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670078793; a=rsa-sha256; cv=none; b=F/2FKTMTBeQIUEBzFI73mMS8tMUzH3LDe2tX0Tnr3o6T24yKdLPCAIB76xvF25CRNmmit/ WnkjV+buMAFRyA6aYMx08rnDrq0nxHCQ0qmfifiIyHCqPobCeWKtEcKDpDappKfhk3+zMW X8A5yWMqTTGkHH1GHeyCQgazFM4nkqU= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 23CF660B40; Sat, 3 Dec 2022 14:46:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FB38C433C1; Sat, 3 Dec 2022 14:46:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670078791; bh=JbgfFxWkZVdk779jGhAIsqHqSPt5FP1SxGAmrFuhBFQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QbV4kHKpL+u1T/g+OqlY0ljvJlay8TarlFVHe095jScNDZYmha0SARLw9QLBb/ARy 3hdKOV6+D2dB6t3Bx9Sip7ddN/Z4xpttOqrqPwekZzMb0XtiOffFAbYev83LkjBP5v JFD4mbbPdLkwKCbVKWhbyqPs2WXyx5sRHg4Zf4ZKmQ4tZdsWdQvNiKgi6tVWCJIqjm kE6AOuDnLLiYfVRbwDLIBokDR6YFUbq2LOfaG6WhlUEBjfvFuK7Rc1ZHFIt4r+e1Yd hT3WeAA6NS14zZf5V2X8lN54zoNR19WpdS1A2KO0b+MEUuGIZb0yrNGG5Mk9vg9N4o nikk/i2cqshRg== Date: Sat, 3 Dec 2022 16:46:14 +0200 From: Mike Rapoport To: Thomas Gleixner Cc: Song Liu , bpf@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, akpm@linux-foundation.org, x86@kernel.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, mcgrof@kernel.org Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs Message-ID: References: <87v8mvsd8d.ffs@tglx> <87mt86rbvy.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mt86rbvy.ffs@tglx> X-Stat-Signature: ytcpwoztyzqzmcqornxrwju58hygxibx X-Rspam-User: X-Spamd-Result: default: False [-2.90 / 9.00]; BAYES_HAM(-6.00)[100.00%]; IRL_BL_25(2.00)[52.25.139.140:received]; SUBJECT_HAS_UNDERSCORES(1.00)[]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; RCPT_COUNT_SEVEN(0.00)[11]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[kernel.org:+]; DMARC_POLICY_ALLOW(0.00)[kernel.org,none]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[kernel.org:s=k20201202]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+a:dfw.source.kernel.org]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 1552DC000C X-Rspamd-Server: rspam06 X-HE-Tag: 1670078792-14617 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: Hi Thomas, On Thu, Dec 01, 2022 at 11:34:57PM +0100, Thomas Gleixner wrote: > Mike! > > On Thu, Dec 01 2022 at 22:23, Mike Rapoport wrote: > > On Thu, Dec 01, 2022 at 10:08:18AM +0100, Thomas Gleixner wrote: > >> On Wed, Nov 30 2022 at 08:18, Song Liu wrote: > >> The symptom is iTLB pressure. The root cause is the way how module > >> memory is allocated, which in turn causes the fragmentation into > >> 4k PTEs. That's the same problem for anything which uses module_alloc() > >> to get space for text allocated, e.g. kprobes, tracing.... > > > > There's also dTLB pressure caused by the fragmentation of the direct map. > > The memory allocated with module_alloc() is a priori mapped with 4k PTEs, > > but setting RO in the malloc address space also updates the direct map > > alias and this causes splits of large pages. > > > > It's not clear what causes more performance improvement: avoiding splits of > > large pages in the direct map or reducing iTLB pressure by backing text > > memory with 2M pages. > > From our experiments when doing the first version of the SKX retbleed > mitigation, the main improvement came from reducing iTLB pressure simply > because the iTLB cache is really small. > > The kernel text placement is way beyond suboptimal. If you really do a > hotpath analysis and (manually) place all hot code into one or two 2M > pages, then you can achieve massive performance improvements way above > the 10% range. > > We currently have a master student investigating this, but it will take > some time until usable results materialize. > > > If the major improvement comes from keeping direct map intact, it's > > might be possible to mix data and text in the same 2M page. > > No. That can't work. > > text = RX > data = RW or RO > > If you mix this, then you end up with RWX for the whole 2M page. Not an > option really as you lose _all_ protections in one go. I meant to take one 2M page from the direct map and split it to 4K in the module address space. Then the protection could be done at PTE level after relocations etc and it would save the dance with text poking. But if mapping the code with 2M pages gives massive performance improvements, it's surely better to keep 2M pages in the modules space. > Thanks, > > tglx -- Sincerely yours, Mike.