On Mon, Feb 22, 2010 at 2:37 PM, StephanT <stman937-linewbie@xxxxxxxxx> 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 can't
>> return from the middle and have to wait till we get the resource. For
>> example, consider a write operation being done on a page belonging to
>> a file -by 2 processes. They both can't write to the same page at the
>> same time, so what happens is the kernel locks the first page on
>> behalf of say process 1 and copies data into it, updates its flags and
>> whatever. Now while this is going on, when the other process tries to
>> lock the same page, it will be put to sleep (and added to a wait
>> queue) till the lock is available. You usually don't want to return
>> till you have this resource available. So during this kind of lock,
>> the process is put on a wait queue and when the lock is free, any
>> processes on this queue are woken up. There is usually some sort of a
>> wait queue for each event/resource and on completion of a certain
>> event, processes from these lists are woken up.
>
> I'm little confused here (please correct me if I'm wrong) :
>
> AFAIK when in driver context you wait only for device events.
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
> I mean, even
> you have an interrupt handler or you poll a device register. The other,
> common system resources as memory, pages, locks, timers, ... are taken
> care by the kernel without any action of your side.
Basically agreed, but for clarity:
control structures are very common in drivers. ie. struct
hardware_control_metadata { }
It is not at all uncommon to have access to those restricted via a
semaphore or mutex. If you attempt to get a semaphore or mutex and it
fails the underlying call may very well call schedule for you.
So while your driver in that case would not directly call schedule, it
is indirectly doing so.
> If your driver tries to access
> a page which is not available at a time the kernel would put your driver/user-
> process at sleep until the resource becomes available. No need for the
> driver to do any preventive action. Unless, as pointed in previous answers,
> the driver is in an intended endless loop and wants to let the others to get
> some CPU.
I prefer calling it a polling loop instead of an endless loop, but I
basically agree. In general polling loops should always have a
timeout so even in the presence of a hardware failure they're not
endless.
> For this purpose(driver/device) I do not see any way to specify some wait-condition
> when calling "schedule()".
When you call schedule you have not told the kernel your idle forever,
just "I have nothing else to do this time slice, move on to the next
time slice."
Your priority / nice value will be used by the scheduler to decide
when you will run again. Typically multiple times a second.
If your driver can't ignore the hardware for a relatively long period
of time then "schedule" may not be the call for you. But the general
concept is to get all the high-speed priority work done in the
interrupt driver. So even if it does take a few real seconds for the
scheduler to re-schedule your task (and associated driver) it is not a
big deal.
Obviously the goal is to keep that time down to hundreds of
milliseconds as an example, but in the real world sometimes its much
longer and your code should not fall apart.
> Maybe I miss the point.. From what I see in the actual
> driver code I feel like the driver, if in lengthy operations has to check some "flag"
> and if set to give up the CPU until the kernel calls it again.
Agreed, but the flag is pretty much just "Is anyone else waiting on
the cpu?". Or at least that's my assumption. ie. Why bother calling
schedule if no one else wants the cpu in the first place.
It may also have some power saving feature. I don't know how that
kicks in. ie. If I have a cpu that is only busy driving a low-speed
i/o device, the cpu should drop into a power save mode.
I'm not sure if that concept is relevant to this discussion or not.
Nor do I know how it is implemented.
> Cheers,
> Stephan
Greg
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
