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 D186BC433FE for ; Tue, 29 Nov 2022 23:56:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 074DC6B0072; Tue, 29 Nov 2022 18:56:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 024466B0073; Tue, 29 Nov 2022 18:56:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2E396B0074; Tue, 29 Nov 2022 18:56:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D08346B0072 for ; Tue, 29 Nov 2022 18:56:41 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 98FB41A0AAB for ; Tue, 29 Nov 2022 23:56:41 +0000 (UTC) X-FDA: 80188142202.01.626D70C Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf21.hostedemail.com (Postfix) with ESMTP id D83FF1C000F for ; Tue, 29 Nov 2022 23:56:40 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669766198; 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=ciH+KN2VCKnkPceqB8qk/ZvYiib3qLho11Tk6MOO6VU=; b=16Yf48tjxUPsuw0WulIhQd5+7YojsaluMmMEHlNNZ++g8j8+62QJNjGAFYatJTDU7FbJPi EnxL5XtU1cQZo+9RZkkD5D/4vbwMN8fRATEs9YAkwTcIOcjhHj7rozT9NznyXlMqUpKLxs IF1EHwgm7ndXk7HGJDTHtl5j3Y/R10Sv3gheWJwVrc954aeRLaxJDhhp+4JgIduyb42cyY gKl4X1X0hDkC6yXN/Lj2PCtjwLAsACRmgoA7Dh3a7bB+rOnXACT/AThi9ThzJv+G1hlXSB oCw2FxUG21L8OWMaFHEePvdroatllYsl007svF98j2FhEVn2EoeM/Z+wJJ3yIg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669766198; 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=ciH+KN2VCKnkPceqB8qk/ZvYiib3qLho11Tk6MOO6VU=; b=6r5CjmoRjjS88tPzxoZ/OFxObZfxxLo0X6kpqon4m4URZr0qFe+DJknPuudjP4F4EF6TSf 4UFB1tQ4Xx5LeODA== To: Song Liu Cc: 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, rppt@kernel.org, mcgrof@kernel.org Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs In-Reply-To: References: <20221107223921.3451913-1-song@kernel.org> <87lenuukj0.ffs@tglx> Date: Wed, 30 Nov 2022 00:56:37 +0100 Message-ID: <871qpluxfu.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=16Yf48tj; dkim=pass header.d=linutronix.de header.s=2020e header.b=6r5CjmoR; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669766201; a=rsa-sha256; cv=none; b=errkx/sBFF8jQaoiooJx0ENVdYfsZlqVlg3jNA0vtdRxJyukFgUcHrtWKYSqw8f8cBOG96 8cWt+YyfbkoKXDKtBHVgRuPd1rnoOiIhQTO9SnO23+DpxhUOhsToWOMe3QRvFHiWPK76qD x+V1tBh0AmcsH9GWshG+892UtIdva2U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669766201; 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=ciH+KN2VCKnkPceqB8qk/ZvYiib3qLho11Tk6MOO6VU=; b=sbZeIVHMIIvH15j5auoZRS9yRmTn9R8u+8U5ONzNru5kJsHnpENXBeCRKabYshKtnzN1qO /cV3HKPfp778VJQk0gZvIlHweA6sTEylm1hIXoJS49QWsqbiZf91UOT1emA9yRU3wj/Srb FGh7pU4uwzzF1QfGaGW21/WIRtjwL9g= X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D83FF1C000F Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=16Yf48tj; dkim=pass header.d=linutronix.de header.s=2020e header.b=6r5CjmoR; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Stat-Signature: 91q6p8pu74yxp1egzr4jd4uopskpw89f X-HE-Tag: 1669766200-933451 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: Song, On Tue, Nov 29 2022 at 09:26, Song Liu wrote: > On Tue, Nov 29, 2022 at 2:23 AM Thomas Gleixner wrote: >> Modules are the obvious starting point. Once that is solved pretty much >> everything else falls into place including BPF. >> >> Without modules support this whole exercise is pointless and not going >> anywhere near x86. > > I am not sure I fully understand your point here. Do you mean > > 1) There is something wrong with this solution, that makes it not suitable > for modules; > or > 2) The solution is in the right direction and it will very likely work > for modules. > But we haven't finished module support. ? As I'm obviously unable to express myself coherently, let me try again: A solution which solves the BPF problem, but does not solve the underlying problem of module_alloc() is not acceptable. Is that clear enough? > If it is 1), I would like to understand what are the issues that make it not > suitable for modules. If it is 2), I think a solid, mostly like working small > step toward the right direction is the better way as it makes code reviews > a lot easier and has much lower risks. Does this make sense? No. Because all you are interested in is to get your BPF itch scratched instead of actually sitting down and solving the underlying problem and thereby creating a benefit for everyone. You are not making anything easier. You are violating the basic engineering principle of "Fix the root cause, not the symptom". By doing that you are actually creating more problems than you solve. Why? Clearly your "solution" does not cover the full requirements of the module space because you solely focus on executable memory allocations which somehow magically go into the module address space. Can you coherently explain how this results in a consistent solution for the rest of the module requirements? Can you coherently explain why this wont create problems down the road for anyone who actually would be willing to solve the root cause? No, you can't answer any of these questions simply because you never explored the problem space sufficiently. I'm not the first one to point this out. Quite some people in the various threads regarding this issue have been pointing that out to you before. They even provided you hints on how this can be solved properly once and forever and for everyones benefits. > I would also highlight that part of the benefit of this work comes from > reducing direct map fragmentations. While BPF programs consume less > memory, they are more dynamic and can cause more direct map > fragmentations. bpf_prog_pack in upstream kernel already covers this > part, but this set is a better solution than bpf_prog_pack. > > Finally, I would like to point out that 5/6 and 6/6 of (v5) the set let BPF > programs share a 2MB page with static kernel text. Therefore, even > for systems without many BPF programs, we should already see some > reduction in iTLB misses. Can you please stop this marketing nonsense? As I pointed out to you in the very mail which your are replying to, the influence of BPF on the system I picked randomly out of the pool is pretty close to ZERO. Ergo, the reduction of iTLB misses is going to be equally close to ZERO. What is the benefit you are trying to sell me? I'm happy to run perf on this machine and provide the numbers which put your 'we should already see some reduction' handwaving into perspective. But the above is just a distraction. The real point is: You can highlight and point out the benefits of your BPF specific solution as much as you want, it does not make the fact that you are "fixing" the symptom instead of the root cause magically go away. Again for the record: The iTLB pressure problem, which affects modules, kprobes, tracing and BPF, is caused by the way how module_alloc() is implemented. That's the root cause and this needs to be solved for _ALL_ of the users of this infrastructure and not worked around by adding something which makes BPF shiny and handwaves about that it solves the underlying problem. Thanks, tglx