In Win2k , when DPCs are retired as a result of interrupt at dispatch level,
the current stack is switched to a special stack. As soon as
KiRetireDpcList() finish processing, the old stack is restored.
When the DPCs are retired in the idle loop, no such stack switch occures.
I would want to know , if anyone can explain:
- Why a stack switch is considered necessary .
- Why only for DPCs retired as a reuslt of a dispacth interrupt.
Bye, Dan
“Dan Partelly” wrote in message news:xxxxx@ntdev…
>
> I would want to know , if anyone can explain:
>
> 1. Why a stack switch is considered necessary .
> 2. Why only for DPCs retired as a reuslt of a dispacth interrupt.
>
Here’s my understanding: The stack switch isn’t considered “necessary”, just
desireable. The issue is that interrupts are handled on the kernel stack of
an arbitrary thread. Thus, the amount of stack usage at that point is
arbitrarily large. While it might be reasonable to assume that there’ll be
enough stack for the ISR, there are some devices (some netcards, for
example) that have rather elaborate DPCs that could overflow the stack.
Such a switch isn’t necessary when attempting to retire the DPC list from
idle, because that idle loop is not run in an arbitrary thread context.
Does that make sense?
Peter
OSR
kernel stacks are limited to 12k. We were hitting cases where we’d
process a DPC on a thread which had already heavily used its stack and
ran out during DPC processing. So we switch stacks in this case.
the idle thread is one the system controls and it does just about
nothing so its stack is usually almost entirely free. There’s no reason
to incur the cost of stack switching to process DPCs in this case (a
case which I believe is fairly common)
-p
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Wednesday, September 04, 2002 6:42 AM
To: NT Developers Interest List
Subject: [ntdev] DPC Retire
In Win2k , when DPCs are retired as a result of interrupt at dispatch
level, the current stack is switched to a special stack. As soon as
KiRetireDpcList() finish processing, the old stack is restored.
When the DPCs are retired in the idle loop, no such stack switch
occures.
I would want to know , if anyone can explain:
- Why a stack switch is considered necessary .
- Why only for DPCs retired as a reuslt of a dispacth interrupt.
Bye, Dan
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
Yaps , it does.
Thank you both.
----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Wednesday, September 04, 2002 6:07 PM
Subject: [ntdev] Re: DPC Retire
>
> “Dan Partelly” wrote in message
news:xxxxx@ntdev…
> >
> > I would want to know , if anyone can explain:
> >
> > 1. Why a stack switch is considered necessary .
> > 2. Why only for DPCs retired as a reuslt of a dispacth interrupt.
> >
>
> Here’s my understanding: The stack switch isn’t considered “necessary”,
just
> desireable. The issue is that interrupts are handled on the kernel stack
of
> an arbitrary thread. Thus, the amount of stack usage at that point is
> arbitrarily large. While it might be reasonable to assume that there’ll
be
> enough stack for the ISR, there are some devices (some netcards, for
> example) that have rather elaborate DPCs that could overflow the stack.
>
> Such a switch isn’t necessary when attempting to retire the DPC list from
> idle, because that idle loop is not run in an arbitrary thread context.
>
> Does that make sense?
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
> 1. Why a stack switch is considered necessary .
IMHO to avoid the DPC stack being limited also by the thread’s stack.
Max