Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Jun 2016 09:13:55 -0700
From: Andy Lutomirski <>
To: Michal Hocko <>
Cc: Andy Lutomirski <>, X86 ML <>, 
	"" <>, linux-arch <>, 
	Borislav Petkov <>, Nadav Amit <>, Kees Cook <>, 
	Brian Gerst <>, 
	"" <>, 
	Linus Torvalds <>, Josh Poimboeuf <>, 
	Jann Horn <>, Heiko Carstens <>
Subject: Re: [PATCH v2 06/13] fork: Add generic vmalloced stack support

On Mon, Jun 20, 2016 at 6:36 AM, Michal Hocko <> wrote:
> On Fri 17-06-16 13:00:42, Andy Lutomirski wrote:
>> If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
>> vmalloc_node.
> I like this! It also reduces demand for higher order (order-2) pages
> considerably which is a great plus on its own. I would be little bit
> worried about the performance because vmalloc wasn't the fastest one
> AFAIR. Have you tried to measure that?

It seems to add about 1.5µs to pthread_create+join on my laptop.  (On
an unmodified, stripped-down kernel, it took about 7µs before.  On a
Fedora system, the baseline is much worse.)  I think that most of the
overhead is because vmalloc allocates one page at a time, which means
that it won't use a higher order page even if one is sitting on a

I can imagine better integration with the page allocator in which
higher order pages are used if readily available.  Similarly, vfree
could free pages that happen to be aligned and consecutive as a unit
to avoid the overhead of merging them back together one at a time.

But I'm not planning on doing any of this myself any time soon.  I
just want to get the code working and merged.


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.