Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268497AbUJTPxN (ORCPT ); Wed, 20 Oct 2004 11:53:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268323AbUJTPf3 (ORCPT ); Wed, 20 Oct 2004 11:35:29 -0400 Received: from kinesis.swishmail.com ([209.10.110.86]:27919 "EHLO kinesis.swishmail.com") by vger.kernel.org with ESMTP id S266663AbUJTPca (ORCPT ); Wed, 20 Oct 2004 11:32:30 -0400 Message-ID: <417687BE.5020900@techsource.com> Date: Wed, 20 Oct 2004 11:43:58 -0400 From: Timothy Miller MIME-Version: 1.0 To: Hugh Dickins CC: "Martin J. Bligh" , Andrea Arcangeli , Alan Cox , arjanv@redhat.com, Chris Wedgwood , LKML , Christoph Hellwig Subject: Re: [PATCH 1/3] Separate IRQ-stacks from 4K-stacks option References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1124 Lines: 27 Hugh Dickins wrote: > > Wasn't Andrea worried, a couple of months back, about nested interrupts > overflowing the 4K interrupt stack? He was trying to work out how to > have an 8K interrupt stack even with the 4K task stack, proposed thread > info at both top and bottom of stack; but his "current" still looked to > me like it'd be significantly more costly than the present one. Yeah, one of the driving forces behind going to 4K task stacks is that you significantly reduce the amount of kernel memory reserved for user processes. But then, there came the requirement to keep around a handful of irq stacks which doesn't hurt. Given the finite and small number of IRQ stacks required, I see no reason not to make them 8K, other than for elegance sake. You're not really wasting much memory by giving IRQ's 8k stacks. Yes, I know, it does feel icky, though. :) - 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/