From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by kanga.kvack.org (Postfix) with ESMTP id 916F06B0035 for ; Thu, 29 May 2014 11:24:50 -0400 (EDT) Received: by mail-vc0-f180.google.com with SMTP id hy4so557403vcb.39 for ; Thu, 29 May 2014 08:24:50 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [2607:f8b0:400c:c01::233]) by mx.google.com with ESMTPS id v15si735606vei.0.2014.05.29.08.24.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 08:24:50 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so554529veb.24 for ; Thu, 29 May 2014 08:24:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140529072633.GH6677@dastard> 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> Date: Thu, 29 May 2014 08:24:49 -0700 Message-ID: Subject: Re: [RFC 2/2] x86_64: expand kernel stack to 16K From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Dave Chinner Cc: Jens Axboe , Minchan Kim , 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 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. 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