Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Jun 2019 15:10:27 -0700
From: Andrew Morton <>
To: Alexander Potapenko <>
Cc: Christoph Lameter <>, Kees Cook <>,
 Masahiro Yamada <>, Michal Hocko
 <>, James Morris <>, "Serge E. Hallyn"
 <>, Nick Desaulniers <>, Kostya
 Serebryany <>, Dmitry Vyukov <>, Sandeep
 Patil <>, Laura Abbott <>, Randy
 Dunlap <>, Jann Horn <>, Mark Rutland
 <>, Marco Elver <>,,,
Subject: Re: [PATCH v7 1/2] mm: security: introduce init_on_alloc=1 and
 init_on_free=1 boot options

On Mon, 17 Jun 2019 17:10:49 +0200 Alexander Potapenko <> wrote:

> Slowdown for the new features compared to init_on_free=0,
> init_on_alloc=0:
> hackbench, init_on_free=1:  +7.62% sys time (st.err 0.74%)
> hackbench, init_on_alloc=1: +7.75% sys time (st.err 2.14%)

Sanity check time.  Is anyone really going to use this?  Seriously,
honestly, for real?  If "yes" then how did we determine that?

Also, a bit of a nit: "init_on_alloc" and "init_on_free" aren't very
well chosen names for the boot options - they could refer to any kernel
object at all, really.  init_pages_on_alloc would be better?  I don't think
this matters much - the boot options are already chaotic.  But still...

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.