Hi Joel,
because timers execute in interrupt context, not process context.
What do you mean exactly?
My understanding is the kernel uses interrupts to count the time and to
trigger timer routines - but these routine are executed in the context they
were registered. A timer created by a
On Tue, Feb 23, 2010 at 1:16 PM, StephanT stman937-linew...@yahoo.com wrote:
Hi Joel,
because timers execute in interrupt context, not process context.
What do you mean exactly?
My understanding is the kernel uses interrupts to count the time and to
trigger timer routines - but these
Hi Greg,
Instead there is an intermediary context that I don't think you've
taken into account.
I believe timers are also invoked in this intermediary context. ie.
When a timer invokes a function you can't trust the process / task
structures to relate to your original userspace app.
I
Like for example when a write() happens, this doesn't have to
necessarily go all the way till the disk immediately, instead its
Ofcourse, unless the file is opened in O_DIRECT mode
-Joel
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
On Tue, Feb 23, 2010 at 2:09 PM, Joel Fernandes agnel.j...@gmail.com wrote:
Hi Greg,
Instead there is an intermediary context that I don't think you've
taken into account.
I believe timers are also invoked in this intermediary context. ie.
When a timer invokes a function you can't trust
My understanding is the kernel uses interrupts to count the time and to
trigger timer routines - but these routine are executed in the context they
were registered. A timer created by a process executes in process
context. A driver registered timer executes in kernel context (not interrupt).
Hi Greg,
I'm relatively new to this stuff but I think I will make some bold statements:
With linux today, is there a specific process context (ie. kernel
thread) associated with executing functions triggered by timers firing
off?
No, a timer being fired wouldn't be associated with any single
Hi Greg, Joel,
You're missing a tier of complexity and I'm afraid I don't know the...
Agreed 100% :-)
My intent was not to discuss the whole linux driver topic but to understand
the subtleties of using schedule() in linux drivers.
This point of view I have to say, you guys you did an
Hi Joel,
You need to be clear with yourself on the meaning and the
types/differences of different contexts first, because its really
confusing when you say kernel context (not interrupt).
Could you, please be a little more specific about what is confusing?
As this is learning ground it would
Hi Stephan,
I'm no expert this is what I think:
1. What event awakes the process? Has the driver any way to control it?
The kernel code executing on behalf of the process is usually waiting
for some resource to become available, we sleep because we can't
return from the middle and have to wait
Hi Greg,
Thanks for your message.
You're right that fewer kernels have this, I thought that since
CONFIG_PREEMPT documentation says its for low latency desktops (so
that processes don't wait and the UI is more responsive), most desktop
distros would have it enabled. But even on my Ubuntu 9.10
On Sat, Feb 20, 2010 at 2:01 AM, Joel Fernandes agnel.j...@gmail.com wrote:
In fact the kernel is not interrupt-able in linux as I recall. Thus
a misbehaving driver that enters an infinite loop will hang the whole
machine.
...
Another way to ask your question is Why isn't the linux kernel
Hi Joel,
1. What event awakes the process? Has the driver any way to control it?
The kernel code executing on behalf of the process is usually waiting
for some resource to become available, we sleep because we can't
return from the middle and have to wait till we get the resource. For
On Mon, Feb 22, 2010 at 2:37 PM, StephanT stman937-linew...@yahoo.com wrote:
Hi Joel,
1. What event awakes the process? Has the driver any way to control it?
The kernel code executing on behalf of the process is usually waiting
for some resource to become available, we sleep because we
Hi Greg,
driver context? Not really a kernel term to my knowledge. I'll
assume you mean in a driver directly associated with a user space
call. ie. Not in interrupt mode
Sorry for the formulation. And yes I meant exactly what you suggesting.
It is not at all uncommon to have access to
My understanding is in a driver:
- use schedule() when waiting for kernel services.
- use timers when waiting for the device.
Hi Stephan,
You got it all right except the fact that you cannot use a timer
because timers execute in interrupt context, not process context.
When your Process
Hi Stephan...
Just sharing my humble thoughts...
On Fri, Feb 19, 2010 at 4:39 AM, StephanT stman937-linew...@yahoo.com wrote:
Hello all,
Why would a linux driver call schedule() ?
Basically, to relinquish a certain kernel code path and to switch to
the other one (be it user mode or kernel
On Thu, Feb 18, 2010 at 4:39 PM, StephanT stman937-linew...@yahoo.com wrote:
Hello all,
Why would a linux driver call schedule() ?
The LDD proposes this method to fight systems hangs caused by an infinite
loop in the driver. In this
case the schedule() call would be a workaround. I think
Yeah, schedule() (and __sched prefixed) function call needed when we are
waiting for some events. It would de wasteful to lose CPU cycles while
checking condition what we are waiting for. So, instead we can just to tell
the kernel to switch to another task, and wake up our task when waiting
Hello all,
Why would a linux driver call schedule() ?
The LDD proposes this method to fight systems hangs caused by an infinite loop
in the driver. In this
case the schedule() call would be a workaround. I think better fix the
infinite loop and abstain to call
schedule()...
I found more than
20 matches
Mail list logo
