Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754142AbYH0A61 (ORCPT ); Tue, 26 Aug 2008 20:58:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752730AbYH0A6R (ORCPT ); Tue, 26 Aug 2008 20:58:17 -0400 Received: from py-out-1112.google.com ([64.233.166.177]:34741 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752710AbYH0A6Q (ORCPT ); Tue, 26 Aug 2008 20:58:16 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vV8rvHteS24/AqJN1XJntLqKD6uYEevKBi999MBwh5NzLyCXQTdWzoG1Tre6eYQWr1 q8XFxDvfUXTjhdLJ4wdmxkyjFvOOdUPWSGC894bnnBpzbWaf+68/EnY+PelLyD+T4Fjd FDQUI+2pHfpIsLfr04sa9p02lRRcuajyD0RyU= Message-ID: Date: Tue, 26 Aug 2008 20:58:15 -0400 From: "Parag Warudkar" To: "Linus Torvalds" Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected Cc: "Adrian Bunk" , "Rusty Russell" , "Alan D. Brunelle" , "Rafael J. Wysocki" , "Linux Kernel Mailing List" , "Kernel Testers List" , "Andrew Morton" , "Arjan van de Ven" , "Ingo Molnar" , linux-embedded@vger.kernel.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808261111.19205.rusty@rustcorp.com.au> <20080826183051.GB10925@cs181140183.pp.htv.fi> <20080826205916.GB11734@cs181140183.pp.htv.fi> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1804 Lines: 41 On Tue, Aug 26, 2008 at 7:47 PM, Linus Torvalds wrote: > If that matters, then so should the difference of 3-8 processes' kernel > stack usage when you have a 4k/8k stack choice. The savings part -financial ones- are not always realizable with the way memory is priced/sized/fitted. Savings in few Mb of Kernel stack are not necessarily going to allow getting rid of a single memory chip of 64M or so. Either that or embedded manufacturing/configurations are different than the desktop world. (If my device has 2 memory slots and my user space requires 100Mb including kernel memory - I anyways have to put in 64Mx2 there to take advantage of mass manufactured, general purpose memory - so no big deal if I saved 1.2Mb in Kernel stack or not. And savings of 64Mb Kernel memory are not feasible anyways to allow user space to work with 64Mb.) On the other hand reducing user space memory usage on those devices (not counting savings from kernel stack size) is a way more attractive option. And although you said in your later reply that Linux x86 with 4K stacks should be more than usable - my experiences running a untainted desktop/file server with 4K stack have been always disastrous XFS or not. It _might_ work for some well defined workloads but you would not want to risk 4K stacks otherwise. I understand the having 4K stack option as a non-default for very specific workloads is a good idea but apart from that I think no one else seems to bother with reducing stack sizes (by no one I mean other OSes.) Parag -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/