Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261797AbTEHP0J (ORCPT ); Thu, 8 May 2003 11:26:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261807AbTEHP0J (ORCPT ); Thu, 8 May 2003 11:26:09 -0400 Received: from watch.techsource.com ([209.208.48.130]:1410 "EHLO techsource.com") by vger.kernel.org with ESMTP id S261797AbTEHP0H (ORCPT ); Thu, 8 May 2003 11:26:07 -0400 Message-ID: <3EBA7AE2.9020401@techsource.com> Date: Thu, 08 May 2003 11:42:26 -0400 From: Timothy Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: root@chaos.analogic.com CC: Roland Dreier , Linux kernel Subject: Re: top stack (l)users for 2.5.69 References: <20030507132024.GB18177@wohnheim.fh-wedel.de> <20030507135657.GC18177@wohnheim.fh-wedel.de> <52k7d2pqwm.fsf@topspin.com> <52bryeppb3.fsf@topspin.com> <52n0hyo85x.fsf@topspin.com> <3EB96FB2.2020401@techsource.com> 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: 1814 Lines: 39 Richard B. Johnson wrote: > > In protected mode, the kernel stack. And, regardless of implimentation > details, there can only be one. It's the one whos stack-selector > is being used by the CPU. So, in the case of Linux, with multiple > kernel stacks (!?????), one for each process, whatever process is > running in kernel mode (current) has it's SS active. It's the > one that gets hit with the interrupt. That's kinda what I figured. I just didn't know if there was some (hardware) provision to do otherwise, or if there was some reason why the interrupt handler might immediately switch stacks, etc. That is to say, some CPUs might have provision for a stack pointer to be associated with each interrupt vector. Secondly, given so many unknowns about what might already be on the current kernel stack, it might be generally safer to move the processor state (saved by the CPU on interrupt) from the current stack to some "interrupt stack" which may have a more predictable amount of free space. (Then again, if the CPU is currently executing in user space, the kernel stack is probably completely empty.) I realize that, however small, that would be an undesirable amount of overhead, but it occurs to me that someone might do that anyhow for stability reasons. I could imagine some interrupts needing more than a trivial amount of stack space. I'm assuming, for instance, that things like the IDE block driver would need to do things like PIO a sector to/from an old CDROM drive, look up the next scheduled I/O operation to perform, etc. - 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/