From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by kanga.kvack.org (Postfix) with ESMTP id C2EA66B0035 for ; Thu, 29 May 2014 19:40:18 -0400 (EDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so1045447pbb.11 for ; Thu, 29 May 2014 16:40:18 -0700 (PDT) Received: from lgeamrelo04.lge.com (lgeamrelo04.lge.com. [156.147.1.127]) by mx.google.com with ESMTP id rw8si2964135pab.167.2014.05.29.16.40.16 for ; Thu, 29 May 2014 16:40:17 -0700 (PDT) Date: Fri, 30 May 2014 08:40:51 +0900 From: Minchan Kim Subject: Re: [RFC 2/2] x86_64: expand kernel stack to 16K Message-ID: <20140529234051.GK10092@bbox> References: <1401260039-18189-1-git-send-email-minchan@kernel.org> <1401260039-18189-2-git-send-email-minchan@kernel.org> <20140528223142.GO8554@dastard> <20140529013007.GF6677@dastard> <20140529072633.GH6677@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Dave Chinner , Jens Axboe , Linux Kernel Mailing List , Andrew Morton , linux-mm , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , Mel Gorman , Rik van Riel , Johannes Weiner , Hugh Dickins , Rusty Russell , "Michael S. Tsirkin" , Dave Hansen , Steven Rostedt Hello Linus, On Thu, May 29, 2014 at 08:24:49AM -0700, Linus Torvalds wrote: > On Thu, May 29, 2014 at 12:26 AM, Dave Chinner wrote: > > > > What concerns me about both __alloc_pages_nodemask() and > > kernel_map_pages is that when I look at the code I see functions > > that have no obvious stack usage problem. However, the compiler is > > producing functions with huge stack footprints and it's not at all > > obvious when I read the code. So in this case I'm more concerned > > that we have a major disconnect between the source code structure > > and the code that the compiler produces... > > I agree. In fact, this is the main reason that Minchan's call trace > and this thread has actually convinced me that yes, we really do need > to make x86-64 have a 16kB stack (well, 16kB allocation - there's > still the thread info etc too). > > Usually when we see the stack-smashing traces, they are because > somebody did something stupid. In this case, there are certainly > stupid details, and things I think we should fix, but there is *not* > the usual red flag of "Christ, somebody did something _really_ wrong". > > So I'm not in fact arguing against Minchan's patch of upping > THREAD_SIZE_ORDER to 2 on x86-64, but at the same time stack size does > remain one of my "we really need to be careful" issues, so while I am > basically planning on applying that patch, I _also_ want to make sure > that we fix the problems we do see and not just paper them over. So, should I resend a patch w/o RFC in subject but with Acked-by from Dave? Or, you will do it by yourself? > > The 8kB stack has been somewhat restrictive and painful for a while, > and I'm ok with admitting that it is just getting _too_ damn painful, > but I don't want to just give up entirely when we have a known deep > stack case. > > Linus > > -- > 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 -- Kind regards, Minchan Kim -- 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