On 5/14/07, Bahadir Balban <bahadir.balban@xxxxxxxxx> wrote:
good enough, but i have a query regarding this then.
On a 8K kernel stack system, doesn't interrupts share the stack associated with the current process which was interrupted?
Doesn't interrupt steals the CPU slice time allocated to the running process to run?
Doesn't it run in current process's context ?
What am i missing here?
Thanks
~psr
On 5/14/07, Learning Linux <learninglinux4@xxxxxxxxx> wrote:
> Ok, but how about an ISR, that does not take any locks? Why can't we
> sleep in SUCH an ISR?
> LL
> -
The killer reason why you can't sleep in an interrupt is because an
interrupt is not associated with any context in the first place.
good enough, but i have a query regarding this then.
On a 8K kernel stack system, doesn't interrupts share the stack associated with the current process which was interrupted?
Doesn't interrupt steals the CPU slice time allocated to the running process to run?
Doesn't it run in current process's context ?
What am i missing here?
Thanks
~psr
What
is a context, then? It is the state information for a process. This
includes the kernel and userspace stack pointers, the register set,
and the page tables for that process. The scheduler has access to all
this information, to preempt one process and run another. Contrary to
this, an interrupt, depending on the version of your kernel and arch,
uses a separate irq stack or the kernel stack of the interrupted
process. An irq is not a context but merely a temporary execution to
be concluded asap.
Hope this helps,
Bahadir
--
play the game
