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 F263AC4321E for ; Wed, 30 Nov 2022 09:53:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A91D6B0074; Wed, 30 Nov 2022 04:53:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 659586B0075; Wed, 30 Nov 2022 04:53:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 521F26B0078; Wed, 30 Nov 2022 04:53:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4627F6B0074 for ; Wed, 30 Nov 2022 04:53:33 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1F5E580ECA for ; Wed, 30 Nov 2022 09:53:33 +0000 (UTC) X-FDA: 80189646306.25.7024BDD Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf15.hostedemail.com (Postfix) with ESMTP id 82A8FA000F for ; Wed, 30 Nov 2022 09:53:31 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id E6878B81A94; Wed, 30 Nov 2022 09:53:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 030EEC433D6; Wed, 30 Nov 2022 09:53:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669802008; bh=8LDAH5jowxJdqYzypcXmz8TIH3y51pjOj93bPJGjblc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VlIjuvV5EafTOoAIfX60xMoCjWT7vKPKVPwGMDrj8m4otGJoxz1Kbi/ZwjtxmU5Dk FWgtEnIY20plDJPmPBa5Ekf+owWSA9n7WD38DywXpuxpX6w+fFEq0ZT/2SUw+f8FiN qPDeIAZZGMBTCYgcxBZD8MlXE8azTO1maWV88badkcqZMt3nDU12Ms6bR8jPlsjiXA uRZhrt9w4FmKUPnXc5Odv55zVe49ozFlAiHA4/GGXDnUNSs8wey86sWdmF513BIVVE VIj17/Ym3L4UW4bZGuawYM/D2ALlLNGCdtC35KcYDEo05lJgxMJ0n8LriarKG0B3C/ yB4LnfBvtinnA== Date: Wed, 30 Nov 2022 11:53:09 +0200 From: Mike Rapoport To: Song Liu Cc: Luis Chamberlain , Mel Gorman , Michal Hocko , Aaron Lu , Linus Torvalds , tglx@linutronix.de, 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, willy@infradead.org, dave@stgolabs.net, a.manzanares@samsung.com, Javier =?iso-8859-1?Q?Gonz=E1lez?= , anton@ozlabs.org, colin.i.king@gmail.com Subject: Re: [PATCH bpf-next v4 0/6] execmem_alloc for BPF programs Message-ID: References: <20221117202322.944661-1-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669802011; a=rsa-sha256; cv=none; b=Tvo9ag1ZYL/UxjlFaVKDjSQxgXpz42OC8qjcydXDe7OFeoAg7lfRPvvXrgYHQgdtNygKYs QIaP9mzDLzju4dNY64hMKlG2YhnHqLjIPQEZtgUnLIqvDnKf0Fj6u1O8iuz5gDMYAmiRms BEfoQhd3oR8TvvkCh5J0Kzoj7QALajo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VlIjuvV5; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 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=1669802011; 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=HTDDLcXmzdNsqxLhICyfI+I82Ir3cAVvBKfu4MicEZ0=; b=Hd/dsmn6MfEvbTnC1Jhe2hRxLGPTq+dMb2IdDSvjiP6y5zkctPs9ppYrwSbQwjo2DL2Xo4 JPuRS2iov0+Udn94GwisfzHOA8ujiWpamGir/6dUkiZBihY+Yf//6r8SgJ0YHq7BeOIeH8 s50W1PEa0veJ4XMiH5s4Uq9mrmgC6+Q= X-Stat-Signature: 7psioznjresfiuuors3y117pc1795xjk X-Rspamd-Queue-Id: 82A8FA000F X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VlIjuvV5; spf=pass (imf15.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam05 X-HE-Tag: 1669802011-11389 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 Tue, Nov 22, 2022 at 10:06:06PM -0700, Song Liu wrote: > On Tue, Nov 22, 2022 at 5:21 PM Luis Chamberlain wrote: > > > > On Mon, Nov 21, 2022 at 07:28:36PM -0700, Song Liu wrote: > > > On Mon, Nov 21, 2022 at 1:12 PM Luis Chamberlain wrote: > > > > > [...] > > > fixes a bug that splits the page table (from 2MB to 4kB) for the WHOLE kernel > > > text. The bug stayed in the kernel for almost a year. None of all the available > > > open source benchmark had caught it before this specific benchmark. > > > > That doesn't mean enterpise level testing would not have caught it, and > > enteprise kernels run on ancient kernels so they would not catch up that > > fast. RHEL uses even more ancient kernels than SUSE so let's consider > > where SUSE was during this regression. The commit you mentioned the fix > > 7af0145067bc went upstream on v5.3-rc7~4^2, and that was in August 2019. > > The bug was introduced through commit 585948f4f695 ("x86/mm/cpa: Avoid > > the 4k pages check completely") and that was on v4.20-rc1~159^2~41 > > around September 2018. Around September 2018, the time the regression was > > committed, the most bleeding edge Enterprise Linux kernel in the industry was > > that on SLE15 and so v4.12 and so there is no way in hell the performance > > team at SUSE for instance would have even come close to evaluating code with > > that regression. In fact, they wouldn't come accross it in testing until > > SLE15-SP2 on the v5.3 kernel but by then the regression would have been fixed. > > Can you refer me to one enterprise performance report with open source > benchmark that shows ~1% performance regression? If it is available, I am > more than happy to try it out. Note that, we need some BPF programs to show > the benefit of this set. In most production hosts, network related BPF programs > are the busiest. Therefore, single host benchmarks will not show the benefit. > > Thanks, > Song > > PS: Data in [1] if full of noise: > > """ > 2. For each benchmark/system combination, the 1G mapping had the highest > performance for 45% of the tests, 2M for ~30%, and 4k for~20%. > > 3. From the average delta, among 1G/2M/4K, 4K gets the lowest > performance in all the 4 test machines, while 1G gets the best > performance on 2 test machines and 2M gets the best performance on the > other 2 machines. > """ I don't think it's noise. IMO, this means that performance degradation caused by the fragmentation of the direct map highly depends on workload and microarchitecture. > There is no way we can get consistent result of 1% performance improvement > from experiments like those. Experiments like those show how a change in the kernel behaviour affects different workloads and not a single benchmark. Having a performance improvement in a single benchmark does necessarily not mean other benchmarks won't regress. > [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/ -- Sincerely yours, Mike.