From: Song Liu <song@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: "Mel Gorman" <mgorman@suse.de>,
"Michal Hocko" <mhocko@kernel.org>,
"Aaron Lu" <aaron.lu@intel.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
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, rppt@kernel.org,
willy@infradead.org, dave@stgolabs.net, a.manzanares@samsung.com,
"Javier González" <javier.gonz@samsung.com>,
anton@ozlabs.org, colin.i.king@gmail.com
Subject: Re: [PATCH bpf-next v4 0/6] execmem_alloc for BPF programs
Date: Tue, 22 Nov 2022 22:06:06 -0700 [thread overview]
Message-ID: <CAPhsuW5g02Ahub+OX5WomzP24E74-T4K_x8pr1rkiC3uba2QBw@mail.gmail.com> (raw)
In-Reply-To: <Y31ngcvzHCzWTg1f@bombadil.infradead.org>
On Tue, Nov 22, 2022 at 5:21 PM Luis Chamberlain <mcgrof@kernel.org> 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 <mcgrof@kernel.org> 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.
"""
There is no way we can get consistent result of 1% performance improvement
from experiments like those.
[1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com/
next prev parent reply other threads:[~2022-11-23 5:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 20:23 Song Liu
2022-11-17 20:23 ` [PATCH bpf-next v4 1/6] vmalloc: introduce execmem_alloc, execmem_free, and execmem_fill Song Liu
[not found] ` <882e2964-932e-0113-d3cd-344281add3a1@iogearbox.net>
2022-11-21 15:55 ` Christoph Hellwig
2022-11-21 16:29 ` Song Liu
2022-11-21 19:55 ` Luis Chamberlain
2022-11-22 2:55 ` Song Liu
2022-11-22 6:13 ` Christoph Hellwig
2022-11-22 17:25 ` Song Liu
2022-11-28 17:53 ` Song Liu
2022-11-17 20:23 ` [PATCH bpf-next v4 2/6] x86/alternative: support execmem_alloc() and execmem_free() Song Liu
2022-11-17 20:23 ` [PATCH bpf-next v4 3/6] selftests/vm: extend test_vmalloc to test execmem_* APIs Song Liu
2022-11-17 20:23 ` [PATCH bpf-next v4 4/6] bpf: use execmem_alloc for bpf program and bpf dispatcher Song Liu
2022-11-17 20:23 ` [PATCH bpf-next v4 5/6] vmalloc: introduce register_text_tail_vm() Song Liu
2022-11-17 20:23 ` [PATCH bpf-next v4 6/6] x86: use register_text_tail_vm Song Liu
2022-11-21 20:12 ` [PATCH bpf-next v4 0/6] execmem_alloc for BPF programs Luis Chamberlain
2022-11-21 20:20 ` Luis Chamberlain
2022-11-22 2:36 ` Song Liu
2022-12-08 2:48 ` Luis Chamberlain
2022-11-22 2:28 ` Song Liu
2022-11-23 0:21 ` Luis Chamberlain
2022-11-23 5:06 ` Song Liu [this message]
2022-11-30 9:53 ` Mike Rapoport
2022-11-30 9:41 ` Mike Rapoport
2022-11-22 2:55 ` Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPhsuW5g02Ahub+OX5WomzP24E74-T4K_x8pr1rkiC3uba2QBw@mail.gmail.com \
--to=song@kernel.org \
--cc=a.manzanares@samsung.com \
--cc=aaron.lu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=anton@ozlabs.org \
--cc=bpf@vger.kernel.org \
--cc=colin.i.king@gmail.com \
--cc=dave@stgolabs.net \
--cc=hch@lst.de \
--cc=javier.gonz@samsung.com \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox