From: Kees Cook <keescook@chromium.org>
To: Alexander Popov <alex.popov@linux.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Laura Abbott <labbott@redhat.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org,
Network Development <netdev@vger.kernel.org>,
linux-usb@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
dev@openvswitch.org, linux-kbuild <linux-kbuild@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Greg KH <gregkh@linuxfoundation.org>,
Jann Horn <jannh@google.com>,
William Kucharski <william.kucharski@oracle.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Edwin Zimmerman <edwin@211mainstreet.net>,
Matthew Wilcox <willy@infradead.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: Re: [PATCH 0/3] gcc-plugins: Introduce stackinit plugin
Date: Tue, 12 Feb 2019 09:54:38 -0800 [thread overview]
Message-ID: <CAGXu5j+xz8_wkY2rVRML_iq1o7ZoF1jVp2mi73LjxaKuMNw1cw@mail.gmail.com> (raw)
In-Reply-To: <874b8c23-068b-f8e7-2168-12947c06e145@linux.com>
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov <alex.popov@linux.com> wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of the initialization of all stack
> variables. So I did a very brief test with this plugin on top of 4.20.5.
>
> hackbench on Intel Core i7-4770 showed ~0.7% slowdown.
> hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown.
Thanks for looking at this! I'll be including my hackbench
measurements for the v2 here in a moment.
> This test involves the kernel scheduler and allocator. I can't say whether they
> use stack aggressively. Maybe performance tests of other subsystems (e.g.
> network subsystem) can show different numbers. Did you try?
I haven't found a stable network test yet. If someone can find a
reasonable workload, I'd love to hear about it.
> I've heard a hypothesis that the initialization of all stack variables would
> pollute CPU caches, which is critical for some types of computations. Maybe some
> micro-benchmarks can disprove/confirm that?
I kind of think micro-benchmarks aren't so useful because they don't
represent a real-world workload. I've heard people talk about SAP-HANA
as a good test, but I can't get my hands on it. I wonder if anyone has
tried "mysqlslap"?
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Alexander Popov <alex.popov@linux.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Laura Abbott <labbott@redhat.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org,
Network Development <netdev@vger.kernel.org>,
linux-usb@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
dev@openvswitch.org, linux-kbuild <linux-kbuild@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Greg KH <gregkh@linuxfoundation.org>,
Jann Horn <jannh@google.com>,
William Kucharski <william.kucharski@oracle.com>
Subject: Re: [PATCH 0/3] gcc-plugins: Introduce stackinit plugin
Date: Tue, 12 Feb 2019 09:54:38 -0800 [thread overview]
Message-ID: <CAGXu5j+xz8_wkY2rVRML_iq1o7ZoF1jVp2mi73LjxaKuMNw1cw@mail.gmail.com> (raw)
In-Reply-To: <874b8c23-068b-f8e7-2168-12947c06e145@linux.com>
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov <alex.popov@linux.com> wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of the initialization of all stack
> variables. So I did a very brief test with this plugin on top of 4.20.5.
>
> hackbench on Intel Core i7-4770 showed ~0.7% slowdown.
> hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown.
Thanks for looking at this! I'll be including my hackbench
measurements for the v2 here in a moment.
> This test involves the kernel scheduler and allocator. I can't say whether they
> use stack aggressively. Maybe performance tests of other subsystems (e.g.
> network subsystem) can show different numbers. Did you try?
I haven't found a stable network test yet. If someone can find a
reasonable workload, I'd love to hear about it.
> I've heard a hypothesis that the initialization of all stack variables would
> pollute CPU caches, which is critical for some types of computations. Maybe some
> micro-benchmarks can disprove/confirm that?
I kind of think micro-benchmarks aren't so useful because they don't
represent a real-world workload. I've heard people talk about SAP-HANA
as a good test, but I can't get my hands on it. I wonder if anyone has
tried "mysqlslap"?
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH 0/3] gcc-plugins: Introduce stackinit plugin
Date: Tue, 12 Feb 2019 09:54:38 -0800 [thread overview]
Message-ID: <CAGXu5j+xz8_wkY2rVRML_iq1o7ZoF1jVp2mi73LjxaKuMNw1cw@mail.gmail.com> (raw)
In-Reply-To: <874b8c23-068b-f8e7-2168-12947c06e145@linux.com>
On Mon, Jan 28, 2019 at 4:12 PM Alexander Popov <alex.popov@linux.com> wrote:
>
> On 23.01.2019 14:03, Kees Cook wrote:
> > This adds a new plugin "stackinit" that attempts to perform unconditional
> > initialization of all stack variables
>
> Hello Kees! Hello everyone!
>
> I was curious about the performance impact of the initialization of all stack
> variables. So I did a very brief test with this plugin on top of 4.20.5.
>
> hackbench on Intel Core i7-4770 showed ~0.7% slowdown.
> hackbench on Kirin 620 (ARM Cortex-A53 Octa-core 1.2GHz) showed ~1.3% slowdown.
Thanks for looking at this! I'll be including my hackbench
measurements for the v2 here in a moment.
> This test involves the kernel scheduler and allocator. I can't say whether they
> use stack aggressively. Maybe performance tests of other subsystems (e.g.
> network subsystem) can show different numbers. Did you try?
I haven't found a stable network test yet. If someone can find a
reasonable workload, I'd love to hear about it.
> I've heard a hypothesis that the initialization of all stack variables would
> pollute CPU caches, which is critical for some types of computations. Maybe some
> micro-benchmarks can disprove/confirm that?
I kind of think micro-benchmarks aren't so useful because they don't
represent a real-world workload. I've heard people talk about SAP-HANA
as a good test, but I can't get my hands on it. I wonder if anyone has
tried "mysqlslap"?
--
Kees Cook
next prev parent reply other threads:[~2019-02-12 17:54 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 11:03 [PATCH 0/3] gcc-plugins: Introduce stackinit plugin Kees Cook
2019-01-23 11:03 ` [Intel-wired-lan] " Kees Cook
2019-01-23 11:03 ` [PATCH 1/3] treewide: Lift switch variables out of switches Kees Cook
2019-01-23 11:03 ` Kees Cook
2019-01-23 11:03 ` [Intel-wired-lan] " Kees Cook
2019-01-23 11:03 ` Kees Cook
2019-01-23 11:03 ` [1/3] " Kees Cook
2019-01-23 11:58 ` [PATCH 1/3] " Greg KH
2019-01-23 11:58 ` Greg KH
2019-01-23 11:58 ` [Intel-wired-lan] " Greg KH
2019-01-23 11:58 ` [1/3] " Greg Kroah-Hartman
2019-01-23 12:09 ` [PATCH 1/3] " Jann Horn
2019-01-23 12:09 ` Jann Horn
2019-01-23 12:09 ` [Intel-wired-lan] " Jann Horn
2019-01-23 12:09 ` Jann Horn
2019-01-23 12:09 ` [1/3] " Jann Horn
2019-01-23 12:12 ` [PATCH 1/3] " Ard Biesheuvel
2019-01-23 12:12 ` Ard Biesheuvel
2019-01-23 12:12 ` [Intel-wired-lan] " Ard Biesheuvel
2019-01-23 12:12 ` Ard Biesheuvel
2019-01-23 12:12 ` [1/3] " Ard Biesheuvel
2019-01-23 13:21 ` [PATCH 1/3] " William Kucharski
2019-01-23 13:21 ` William Kucharski
2019-01-23 13:21 ` [Intel-wired-lan] " William Kucharski
2019-01-23 13:21 ` [1/3] " William Kucharski
2019-01-23 14:17 ` [Intel-gfx] [PATCH 1/3] " Jani Nikula
2019-01-23 14:17 ` [Intel-wired-lan] " Jani Nikula
2019-01-23 14:17 ` Jani Nikula
2019-01-23 14:17 ` [1/3] " Jani Nikula
2019-01-23 14:23 ` [Intel-gfx] [PATCH 1/3] " Jani Nikula
2019-01-23 14:23 ` Jani Nikula
2019-01-23 14:23 ` [Intel-wired-lan] " Jani Nikula
2019-01-23 14:23 ` [1/3] " Jani Nikula
2019-01-23 14:47 ` [Intel-gfx] [PATCH 1/3] " Edwin Zimmerman
2019-01-23 14:47 ` [Intel-wired-lan] " Edwin Zimmerman
2019-01-23 14:47 ` Edwin Zimmerman
2019-01-23 14:47 ` [1/3] " Edwin Zimmerman
2019-01-23 14:47 ` [Intel-gfx] [PATCH 1/3] " Edwin Zimmerman
2019-01-23 15:46 ` Jani Nikula
2019-01-23 15:46 ` Jani Nikula
2019-01-23 15:46 ` [Intel-wired-lan] " Jani Nikula
2019-01-23 15:46 ` Jani Nikula
2019-01-23 15:46 ` [1/3] " Jani Nikula
2019-01-23 18:55 ` [Intel-gfx] [PATCH 1/3] " Kees Cook
2019-01-23 18:55 ` [Intel-wired-lan] " Kees Cook
2019-01-23 18:55 ` Kees Cook
2019-01-23 18:55 ` [1/3] " Kees Cook
2019-01-23 18:55 ` [Intel-gfx] [PATCH 1/3] " Kees Cook
2019-01-24 8:10 ` Greg KH
2019-01-24 8:10 ` Greg KH
2019-01-24 8:10 ` [Intel-wired-lan] " Greg KH
2019-01-24 8:10 ` [1/3] " Greg Kroah-Hartman
2019-01-24 8:10 ` [Intel-gfx] [PATCH 1/3] " Greg KH
2019-01-23 18:55 ` Kees Cook
2019-01-23 19:18 ` Matthew Wilcox
2019-01-23 19:18 ` [Intel-wired-lan] " Matthew Wilcox
2019-01-23 19:18 ` [1/3] " Matthew Wilcox
2019-01-23 20:36 ` [Intel-gfx] [PATCH 1/3] " Kees Cook
2019-01-23 20:36 ` Kees Cook
2019-01-23 20:36 ` [Intel-wired-lan] " Kees Cook
2019-01-23 20:36 ` Kees Cook
2019-01-23 20:36 ` [1/3] " Kees Cook
2019-01-23 20:36 ` [Intel-gfx] [PATCH 1/3] " Kees Cook
2019-01-23 19:18 ` Matthew Wilcox
2019-01-23 14:17 ` Jani Nikula
2019-01-23 16:51 ` [Intel-wired-lan] " Jeff Kirsher
2019-01-23 16:51 ` Jeff Kirsher
2019-01-23 16:51 ` Jeff Kirsher
2019-01-23 16:51 ` [1/3] " Jeff Kirsher
2019-01-23 16:51 ` [Intel-wired-lan] [PATCH 1/3] " Jeff Kirsher
2019-01-24 12:58 ` Edwin Zimmerman
2019-01-24 12:58 ` [Intel-wired-lan] " Edwin Zimmerman
2019-01-24 12:58 ` [1/3] " Edwin Zimmerman
2019-01-24 12:58 ` [PATCH 1/3] " Edwin Zimmerman
2019-01-24 12:58 ` Edwin Zimmerman
2019-01-23 11:03 ` [PATCH 2/3] gcc-plugins: Introduce stackinit plugin Kees Cook
2019-01-23 11:03 ` [Intel-wired-lan] " Kees Cook
2019-01-23 11:03 ` Kees Cook
2019-01-23 11:03 ` [2/3] " Kees Cook
2019-01-23 11:03 ` [PATCH 2/3] " Kees Cook
2019-01-23 11:03 ` [PATCH 3/3] lib: Introduce test_stackinit module Kees Cook
2019-01-23 11:03 ` [Intel-wired-lan] " Kees Cook
2019-01-23 11:03 ` Kees Cook
2019-01-23 11:03 ` [3/3] " Kees Cook
2019-01-23 11:03 ` [PATCH 3/3] " Kees Cook
2019-01-23 11:20 ` ✗ Fi.CI.BAT: failure for gcc-plugins: Introduce stackinit plugin Patchwork
2019-01-23 14:26 ` Jani Nikula
2019-01-29 0:12 ` [PATCH 0/3] " Alexander Popov
2019-01-29 0:12 ` Alexander Popov
2019-01-29 0:12 ` [Intel-wired-lan] " Alexander Popov
2019-02-12 17:54 ` Kees Cook
2019-02-12 17:54 ` Kees Cook [this message]
2019-02-12 17:54 ` [Intel-wired-lan] " Kees Cook
2019-02-12 17:54 ` Kees Cook
2019-02-12 17:54 ` Kees Cook
2019-02-12 17:54 ` Kees Cook
-- strict thread matches above, loose matches on Subject: below --
2019-01-23 11:03 Kees Cook
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=CAGXu5j+xz8_wkY2rVRML_iq1o7ZoF1jVp2mi73LjxaKuMNw1cw@mail.gmail.com \
--to=keescook@chromium.org \
--cc=alex.popov@linux.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dev@openvswitch.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=edwin@211mainstreet.net \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jani.nikula@linux.intel.com \
--cc=jannh@google.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=william.kucharski@oracle.com \
--cc=willy@infradead.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.