Re: Why can't we sleep in an ISR?

["pradeep singh" <2500.pradeep@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]

On 5/15/07, Dong Feng <middle.fengdong@gmail.com> wrote:
>
> > >
> > > I don't think so but I am not sure.
> >
> > Aliter, i think so.How can an interrupt's execution time go
> > unaccounted then?
> > I guess it does not, only the current processes running
> > time is accounted for.
> > Thoughts?
> >
>
> The interrupt handler's execution time will definitely defer the
> execution of the process, but I think it does not steal the process's
> time slice (the time_slice field not subtracted).


Ok, if i accept this, how does that explains this-

Following code snippet is from main schedule() function[kernel 2.6.20.1] -

now = sched_clock();
if(likely((long long)(now - prev->timestamp) < NS_MAX_SLEEP_AVG)) {
       run_time = now - prev->timestamp;
       /* blah blah */
} else
            run_time = NS_MAX_SLEEP_AVG;

Now,
AFAIK runtime = now - prev->timestamp; will get you a value which (
prev->timestamp is *stamped* during previous
switching of the tasks) is difference of this previous stamp and now value.
Assuming before this schedule() an interrupt was served, then where did the
time spent in ISR accounting is adjusted? I guess this is the code, where
it is checking for a *possible*  runtime to overshoot its stipulated
NS_MAX_SLEEP_AVG and resetting this. Isn't it?
And exactly why would that happen?
Perhaps because the process was about to expire its slice when somebody
barged in and stole its share and also overshot the stipulated time(may be
very less though).

Can you help me in clearing this?

> > > Doesn't it run in current process's context ?
> > > >
> > >
> > > No. I think the concept of process context is a higher-level logical
> > > concept. Though the interrupt share stack with the interrupted
> > > process, in my opinion it logically does not share the context with
> > > the process.
> >
> > Yes, you are right as i can infer. thats why ISRs
> > are special kernel control paths.
> > But the poster asked, why can't we make ISRs to
> > share context with the interrupted process
> > if
> > it not holding any locks? This is rather a desing issues
> > IMO rather than imlementation, isnt it?
> >
> > I guess even if it is possible, it would over complicate the handler
> code.
> > Better trying to keep it simple i guess. Please CMIIW
>
> My understanding is, the ISR is in different context from the process
> because of the definition of term *context*. In my opinion, to say two
> code pieces running in the same context means that two pieces of code
> has some logical relationship to meet a common objective. That's why I
> said *context* is a higher-level logical concept. It's not a concept
> defined in the level of hardware or code implementation, but instead
> in the level of logical. I think, by its definition, it makes no sense
> to say an ISR share context with the process interrupted by it because
> an ISR just randomly interrupts a process, with no logical
> relationship.


Right agreed.

Thanks
~psr


-- 
play the game

[-- Attachment #2: Type: text/html, Size: 4407 bytes --]