Re: Interrupt context...
- From: Nix <nix-razor-pit@xxxxxxxxxxxxx>
- Date: Wed, 07 Dec 2005 16:25:04 +0000
On Thu, 01 Dec 2005, Kasper Dupont mused:
> It is allocated in kernel space, but the size depends on
> architecture and kernel version. It used to be 8KB but in
> 2.6 an option was introduced to reduce it to 4KB. There
> has been talk about removing the 8KB option and making it
> 4KB on future kernels. This applies at least to i386, I'm
> not so sure about other architectures. I think some
> architectures used to have 16KB stacks, but I'm not sure
> about that.
Indeed; SPARC64, for instance, uses 16Kb stacks if the page size is 8kb,
and a stack the same size as the page size if the page size is
larger. Similar things apply to IA64.
x86-64 appears to use 8Kb stacks right now.
> For smaller stacks to work it is important that
> interrupts execute on a seperate stack. The way Linux was
> originally designed would require an interrupt stack to
> have the same size as the kernel stack for a thread, but
> that may have changed.
This is arch-dependent now, I think. Using radically different sizes is
probably excessively risky. :)
>> if yes, then does it puts a upper limit on
>> number of process that can be run on linux (since there is only < 1GB
>> on which we have to allocate 8K kernel stack for each process being
>> run)?
>
> That is correct. But there are other reasons why the number
> of threads would be limited. The stack is not the only
> kernel memory that must be allocated for a thread. But it
> may be the largest.
It's probably the largest per-task structure that's locked into memory,
though. Especially on systems with small amounts of RAM, it can eat
a quite significant amount.
(And as you imply it's a limit on thread number, not process number.)
>> what is the place holder (data structure) in 1GB kernel that
>> maintain all the Kernel stacks for all process?
>
> I'm not sure I understand that question. But I think the
> answer is the struct task_struct. On some architechtures
> this is located at the bottom of the stack, that way the
> stack pointer can be used to locate the task_struct of
> the current thread. On each architecture there is a
> current macro, that will return a pointer to the task_struct
> of the current thread. These structs have pointers to
> each other and lots of other kernel data structures. And
> there are pointers to task_structs in a lot of places in
> the kernel data structures.
He might be asking how the task_structs are chained together (to use a
misleading form of words) and what keeps track of them. In which case,
well, the scheduler, mostly, as you say below.
>> How is the
>> architecture? Assuming kernel is a process
>
> ...is an incorrect assumption.
.... on any Unixlike system, in fact (Linux is not special in this
respect).
> Other architectures
> may be entirely different, but I guess most have some
> kind of interrupt controller.
Indeed, generally very much more capable than that horrid 1980s-vintage
PIC rubbish.
--
`Y'know, London's nice at this time of year. If you like your cities
freezing cold and full of surly gits.' --- David Damerell
.
- References:
- Interrupt context...
- From: arijit.p@xxxxxxxxx
- Re: Interrupt context...
- From: Kasper Dupont
- Interrupt context...
- Prev by Date: Re: dynamic linker problem with libpthread.so.0?
- Next by Date: Re: kernel versions difference question
- Previous by thread: Re: Interrupt context...
- Next by thread: interrupts
- Index(es):
Relevant Pages
|
