From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by kanga.kvack.org (Postfix) with ESMTP id D52256B0035 for ; Fri, 30 May 2014 13:26:17 -0400 (EDT) Received: by mail-pa0-f44.google.com with SMTP id lj1so1926940pab.17 for ; Fri, 30 May 2014 10:26:17 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com. [134.134.136.20]) by mx.google.com with ESMTP id gu3si6336956pbb.232.2014.05.30.10.26.14 for ; Fri, 30 May 2014 10:26:17 -0700 (PDT) Message-ID: <5388BEDF.3000202@intel.com> Date: Fri, 30 May 2014 10:24:47 -0700 From: Dave Hansen MIME-Version: 1.0 Subject: Re: [RFC 2/2] x86_64: expand kernel stack to 16K References: <20140528223142.GO8554@dastard> <20140529013007.GF6677@dastard> <20140529072633.GH6677@dastard> <20140529235308.GA14410@dastard> <20140530000649.GA3477@redhat.com> <20140530002113.GC14410@dastard> <20140530003219.GN10092@bbox> <20140530013414.GF14410@dastard> <5388A2D9.3080708@zytor.com> <5388A935.9050506@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds , "H. Peter Anvin" Cc: Dave Chinner , Minchan Kim , Dave Jones , Jens Axboe , Linux Kernel Mailing List , Andrew Morton , linux-mm , Ingo Molnar , Peter Zijlstra , Mel Gorman , Rik van Riel , Johannes Weiner , Hugh Dickins , Rusty Russell , "Michael S. Tsirkin" , Steven Rostedt , PJ Waskiewicz On 05/30/2014 09:06 AM, Linus Torvalds wrote: > On Fri, May 30, 2014 at 8:52 AM, H. Peter Anvin wrote: >>> That said, it's still likely a non-production option due to the page >>> table games we'd have to play at fork/clone time. >> >> Still, seems much more tractable. > > We might be able to make it more attractive by having a small > front-end cache of the 16kB allocations with the second page unmapped. > That would at least capture the common "lots of short-lived processes" > case without having to do kernel page table work. If we want to use 4k mappings, we'd need to move the stack over to using vmalloc() (or at least be out of the linear mapping) to avoid breaking up the linear map's page tables too much. Doing that, we'd actually not _have_ to worry about fragmentation, and we could actually utilize the per-cpu-pageset code since we'd could be back to using order-0 pages. So it's at least not all a loss. Although, I do remember playing with 4k stacks back in the 32-bit days and not getting much of a win with it. We'd definitely that cache, if for no other reason than the vmalloc/vmap code as-is isn't super-scalable. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org