On 5/15/07, Dong Feng <middle.fengdong@xxxxxxxxx
> wrote:
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?
Right agreed.
> >
> > 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
