From: Yin Fengwei <fengwei.yin@intel.com>
To: Kees Cook <keescook@chromium.org>,
kernel test robot <oliver.sang@intel.com>
Cc: "Mickaël Salaün" <mic@digikod.net>,
lkp@lists.01.org, lkp@intel.com, ying.huang@intel.com,
feng.tang@intel.com, zhengjun.xing@linux.intel.com,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Aleksa Sarai" <cyphar@cyphar.com>,
"Andy Lutomirski" <luto@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Casey Schaufler" <casey@schaufler-ca.com>,
"Christian Brauner" <christian.brauner@ubuntu.com>,
"Christian Heimes" <christian@python.org>,
"Deven Bowers" <deven.desai@linux.microsoft.com>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Eric Biggers" <ebiggers@kernel.org>,
"Eric Chiang" <ericchiang@google.com>,
"Florian Weimer" <fweimer@redhat.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"James Morris" <jmorris@namei.org>, "Jan Kara" <jack@suse.cz>,
"Jann Horn" <jannh@google.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Lakshmi Ramasubramanian" <nramas@linux.microsoft.com>,
"Madhavan T . Venkataraman" <madvenka@linux.microsoft.com>,
"Matthew Garrett" <mjg59@google.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Miklos Szeredi" <mszeredi@redhat.com>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Paul Moore" <paul@paul-moore.com>,
"Philippe Trébuchet" <philippe.trebuchet@ssi.gouv.fr>,
"Scott Shell" <scottsh@microsoft.com>,
"Shuah Khan" <shuah@kernel.org>,
"Steve Dower" <steve.dower@python.org>,
"Steve Grubb" <sgrubb@redhat.com>,
"Thibaut Sautereau" <thibaut.sautereau@ssi.gouv.fr>,
"Vincent Strubel" <vincent.strubel@ssi.gouv.fr>,
kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
"Mickaël Salaün" <mic@linux.microsoft.com>
Subject: Re: [fs] a0918006f9: netperf.Throughput_tps -11.6% regression
Date: Wed, 10 Nov 2021 09:54:27 +0800 [thread overview]
Message-ID: <129a2714-bad3-6f91-d841-51121bcc6e8d@intel.com> (raw)
In-Reply-To: <202111090920.4958E610D1@keescook>
Hi Kees,
On 11/10/21 1:21 AM, Kees Cook wrote:
>> 555600 -0.1% 555305 netperf.Throughput_total_tps
>> 34725 -0.1% 34706 netperf.Throughput_tps
>>
>>
>> Fengwei also helped review these results and commented:
>> I suppose these three CPUs have different cache policy. It also could be
>> related with netperf throughput testing.
> Does moving the syscall implementation somewhere else change things?
> That's a _huge_ performance change for something that isn't even called.
> What's going on here?
We just tried to do trick change to make sure the new function doesn't
make other kernel function address changed. But didn't try to move around
the new function even it's not called. We could try to move it around to
see the impact to netperf throughput.
We tried the original patch (without change to make sure no kernel function
address patch) on other box. As report, the regression are different on
different CPUs like:
-11.6% vs -5.7% vs 0.1%
So my guess is that the different CPUs on these test box have different
cache policies which cause different performance impact when kernel
functions/data address are different.
Yes. This is strange. We don't know exact reason. Need deeper investigation
on this.
Regards
Yin, Fengwei
>
> -Kees
>
next prev parent reply other threads:[~2021-11-10 11:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 19:24 [PATCH v15 0/3] Add trusted_for(2) (was O_MAYEXEC) Mickaël Salaün
2021-10-12 19:24 ` [PATCH v15 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl Mickaël Salaün
2021-11-05 6:41 ` [fs] a0918006f9: netperf.Throughput_tps -11.6% regression kernel test robot
2021-11-09 17:21 ` Kees Cook
2021-11-10 1:54 ` Yin Fengwei [this message]
2021-11-10 8:52 ` Mickaël Salaün
2021-11-11 3:29 ` Yin Fengwei
2021-11-12 12:25 ` Yin Fengwei
2021-10-12 19:24 ` [PATCH v15 2/3] arch: Wire up trusted_for(2) Mickaël Salaün
2021-10-12 19:24 ` [PATCH v15 3/3] selftest/interpreter: Add tests for trusted_for(2) policies Mickaël Salaün
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=129a2714-bad3-6f91-d841-51121bcc6e8d@intel.com \
--to=fengwei.yin@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=casey@schaufler-ca.com \
--cc=christian.brauner@ubuntu.com \
--cc=christian@python.org \
--cc=corbet@lwn.net \
--cc=cyphar@cyphar.com \
--cc=deven.desai@linux.microsoft.com \
--cc=dvyukov@google.com \
--cc=ebiggers@kernel.org \
--cc=ericchiang@google.com \
--cc=feng.tang@intel.com \
--cc=fweimer@redhat.com \
--cc=geert@linux-m68k.org \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=luto@kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mic@digikod.net \
--cc=mic@linux.microsoft.com \
--cc=mjg59@google.com \
--cc=mszeredi@redhat.com \
--cc=nramas@linux.microsoft.com \
--cc=oliver.sang@intel.com \
--cc=paul@paul-moore.com \
--cc=philippe.trebuchet@ssi.gouv.fr \
--cc=scottsh@microsoft.com \
--cc=sgrubb@redhat.com \
--cc=shuah@kernel.org \
--cc=steve.dower@python.org \
--cc=thibaut.sautereau@ssi.gouv.fr \
--cc=vincent.strubel@ssi.gouv.fr \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=zhengjun.xing@linux.intel.com \
--cc=zohar@linux.ibm.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).