Hi, Phillip,
I have said the gap between you and me is the definition of context.
In Robert's definition, *context* is used in a classification method
and really something in higher-level. And I used that term to explain
why ISR can not sleep.
If you do not like the name, name it your way and
Dong Feng wrote:
OK. I think the gap between you and me is the definition of term
*context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
0-672-32720-1), Page 6, then you will read the following:
in Linux, ... each processor is doing one of three things at any
given moment:
Dong Feng wrote:
OK. I think the gap between you and me is the definition of term
*context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
0-672-32720-1), Page 6, then you will read the following:
in Linux, ... each processor is doing one of three things at any
given moment:
Hi, Phillip,
I have said the gap between you and me is the definition of context.
In Robert's definition, *context* is used in a classification method
and really something in higher-level. And I used that term to explain
why ISR can not sleep.
If you do not like the name, name it your way and
OK. I think the gap between you and me is the definition of term
*context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
0-672-32720-1), Page 6, then you will read the following:
in Linux, ... each processor is doing one of three things at any
given moment:
1. In kernel-space,
Dong Feng wrote:
If what you say were true, then an ISR would be running in the same
context as the interrupted process.
Yes, and it is, as others have said in this thread, which is a good
reason why ISRs can't sleep.
But please check any article or
book, it will say ISR running in
Dong Feng wrote:
If what you say were true, then an ISR would be running in the same
context as the interrupted process.
Yes, and it is, as others have said in this thread, which is a good
reason why ISRs can't sleep.
But please check any article or
book, it will say ISR running in
OK. I think the gap between you and me is the definition of term
*context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
0-672-32720-1), Page 6, then you will read the following:
in Linux, ... each processor is doing one of three things at any
given moment:
1. In kernel-space,
2007/5/16, Phillip Susi <[EMAIL PROTECTED]>:
Dong Feng wrote:
>> 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
> No, the term context here has a specific meaning. It refers to those
> things which flow from the current pointer, including the virtual memory
> space, file descriptor table, current uid, and so forth.
And none of these things are used by an ISR.
> Because the
> current pointer is not
Dong Feng wrote:
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.
No, the term
Yes, you are right in this regard. An interrupt handler does steal the
time slice from the interrupted process.
So now I think it is considered an acceptable deviation in calculating
the process run time as well as determine process scheduling because
an ISR should take very short time to
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).
It will definitely be substracted from the process's time slice.
Because the timeslice is substracted in timer
>
> 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
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?
Yes, I think so.
Doesn't interrupt steals the CPU slice time allocated to the running process
to run?
I don't
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?
Yes, I think so.
Doesn't interrupt steals the CPU slice time allocated to the running process
to run?
I don't
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
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).
It will definitely be substracted from the process's time slice.
Because the timeslice is substracted in timer
Yes, you are right in this regard. An interrupt handler does steal the
time slice from the interrupted process.
So now I think it is considered an acceptable deviation in calculating
the process run time as well as determine process scheduling because
an ISR should take very short time to
Dong Feng wrote:
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.
No, the term
No, the term context here has a specific meaning. It refers to those
things which flow from the current pointer, including the virtual memory
space, file descriptor table, current uid, and so forth.
And none of these things are used by an ISR.
Because the
current pointer is not changed on
2007/5/16, Phillip Susi [EMAIL PROTECTED]:
Dong Feng wrote:
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
I agree that the reason an interrupt can not sleep is because an
interrupt is not associated with any context. But I do not agree that
it is specifically because the scheduler can not *resume* the context.
In early version, the ISR always borrow the stack of the currently
running process, so if
[EMAIL PROTECTED] wrote:
Sleeping in an ISR is not fundamentally impossible - I could design
a multitasker that permitted it - but has significant problems, and
most multitaskers, including Linux, forbid it.
You could design a system in which most ISRs can sleep,
but even then you'll probably
On 5/14/07, Learning Linux <[EMAIL PROTECTED]> 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. What
is a
Sleeping in an ISR is not fundamentally impossible - I could design
a multitasker that permitted it - but has significant problems, and
most multitaskers, including Linux, forbid it.
The first problem is the scheduler. "Sleeping" is actually a call
into the scheduler to choose another process to
My understanding is as follows.
Whenever the kernel code sleeps, it means the latest process running
in user space will have to wait for the event on which the kernel code
sleeps.
It makes sense for an exception handler to sleep because an exception
handler always serves the latest process
Learning Linux wrote:
I have a very basic doubt here ... what makes it impossible to sleep
in an ISR? I mean, I know that the kernel preemption is disabled and
the kernel will panic, but I could not understand why?
First: an ISR is meant to be very quick. It is supposed to do only a
minimum of
> I have a very basic doubt here ... what makes it impossible to sleep
> in an ISR? I mean, I know that the kernel preemption is disabled and
> the kernel will panic, but I could not understand why?
Because the interrupt which you are serving in the
ISR has been masked to avoid preemption(
true
I have a very basic doubt here ... what makes it impossible to sleep
in an ISR? I mean, I know that the kernel preemption is disabled and
the kernel will panic, but I could not understand why?
Because the interrupt which you are serving in the
ISR has been masked to avoid preemption(
true for
Learning Linux wrote:
I have a very basic doubt here ... what makes it impossible to sleep
in an ISR? I mean, I know that the kernel preemption is disabled and
the kernel will panic, but I could not understand why?
First: an ISR is meant to be very quick. It is supposed to do only a
minimum of
My understanding is as follows.
Whenever the kernel code sleeps, it means the latest process running
in user space will have to wait for the event on which the kernel code
sleeps.
It makes sense for an exception handler to sleep because an exception
handler always serves the latest process
Sleeping in an ISR is not fundamentally impossible - I could design
a multitasker that permitted it - but has significant problems, and
most multitaskers, including Linux, forbid it.
The first problem is the scheduler. Sleeping is actually a call
into the scheduler to choose another process to
On 5/14/07, Learning Linux [EMAIL PROTECTED] 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. What
is a
[EMAIL PROTECTED] wrote:
Sleeping in an ISR is not fundamentally impossible - I could design
a multitasker that permitted it - but has significant problems, and
most multitaskers, including Linux, forbid it.
You could design a system in which most ISRs can sleep,
but even then you'll probably
I agree that the reason an interrupt can not sleep is because an
interrupt is not associated with any context. But I do not agree that
it is specifically because the scheduler can not *resume* the context.
In early version, the ISR always borrow the stack of the currently
running process, so if
36 matches
Mail list logo
