Question on schedule() function
Timur Tabi
run? I have an application that simulates my hardware, and it runs with 100% CPU. It
polls on a memory buffer to see if the driver has written any data to this. Yes, it's
inefficient, but it has the advantage of completely de-coupling the driver from the simulator.
Sometimes the driver needs to pause to allow the simulator to run. Can I use the
schedule() function for this? If I call schedule() in my driver, what can I do to make
sure that my user process runs before schedule() returns?
--
Timur Tabi
Staff Software Engineer
timur...@ammasso.com
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
Fawad Lateef
> Can I use the schedule() function to suspend my driver to allow a user-space process to
> run? I have an application that simulates my hardware, and it runs with 100% CPU. It
> polls on a memory buffer to see if the driver has written any data to this. Yes, it's
> inefficient, but it has the advantage of completely de-coupling the driver from the simulator.
Can you explain what you are doing ??? like how u are sharing buffer
b/w user/kernel space, whats the method of polling b/c you are saying
completely de-coupling the driver from the simulator ???
>
> Sometimes the driver needs to pause to allow the simulator to run. Can I use the
> schedule() function for this? If I call schedule() in my driver, what can I do to make
> sure that my user process runs before schedule() returns?
>
Whats your driver do ??? Is it working constantly means in a loop ??
b/c mostly driver fucntions are call-backed from the kernel side !!!
and if your driver is doing work in thread then you might be doing
schedule already !!!
--
Fawad Lateef
Timur Tabi
> Can you explain what you are doing ??? like how u are sharing buffer
> b/w user/kernel space,
I allocate the buffer in the driver, and the application calls mmap() to get a pointer to it.
> whats the method of polling b/c you are saying
> completely de-coupling the driver from the simulator ???
The simulator has a bunch of threads that just run on their own, constantly polling the
memory buffer looking for when something has changed. It's inefficient, but it more
closely matches how the real hardware works.
> Whats your driver do ???
It's a standard network driver.
> Is it working constantly means in a loop ??
No, I was talking about the simulator.
The driver writes data to the memory buffer, and it's supposed to wait until the simulator
writes the response back to the same memory buffer. I just want to know if schedule()
will cause the driver to go to sleep, and give CPU to the simulator application.
Basically, I want to know if the following code will work:
*buffer =100;
while (*buffer == 100) {
schedule();
}
What I want to know is whether the schedule() call will give CPU time to the simulator,
which is running as a user-space process. When the simulator runs, it sees that the
buffer has the value 100, and then it does some calculations, and writes a different value
back to the buffer. This should cause "*buffer == 100" to become false.
--
Timur Tabi
Staff Software Engineer
timur...@ammasso.com
One thing a Southern boy will never say is,
"I don't think duct tape will fix it."
-- Ed Smylie, NASA engineer for Apollo 13
--
Fawad Lateef
>
> > Can you explain what you are doing ??? like how u are sharing buffer
> > b/w user/kernel space,
>
> I allocate the buffer in the driver, and the application calls mmap() to get a pointer to it.
>
ya, ok .... I was thinking in terms of block device driver ;)
> > whats the method of polling b/c you are saying
> > completely de-coupling the driver from the simulator ???
>
> The simulator has a bunch of threads that just run on their own, constantly polling the
> memory buffer looking for when something has changed. It's inefficient, but it more
> closely matches how the real hardware works.
>
its clear to me your way now, as you are using mmap ....
> > Whats your driver do ???
>
> It's a standard network driver.
>
> > Is it working constantly means in a loop ??
>
> No, I was talking about the simulator.
>
> The driver writes data to the memory buffer, and it's supposed to wait until the simulator
> writes the response back to the same memory buffer. I just want to know if schedule()
> will cause the driver to go to sleep, and give CPU to the simulator application.
>
Yes, schedule() will certainly sends your driver to sleep and will
schedule it to run again; thus give certainly time to other
applications to work ...
> Basically, I want to know if the following code will work:
>
> *buffer =100;
> while (*buffer == 100) {
> schedule();
> }
>
> What I want to know is whether the schedule() call will give CPU time to the simulator,
> which is running as a user-space process. When the simulator runs, it sees that the
> buffer has the value 100, and then it does some calculations, and writes a different value
> back to the buffer. This should cause "*buffer == 100" to become false.
>
What i saw is calling schedule in a loop of the kernel thread/process
makes it to use 99% of the CPU, if CPU is not doing other stuffs (and
might slow down the user space too as it has low priority then kernel
space) ... So my idea is to better use schedule_timeout with some
small value, so that load on the CPU will be less ........
--
Fawad Lateef
Mandeep Singh Sandhu
Firtsly, my apologies for the disclaimer! (this is just a one time
mail...till the Disclaimer gets removed :) )
When you say "schedule() will certainly sends your driver to sleep"
I think you mean the "process that called the driver will be put to
sleep"...right??
the driver itself doesn't have any process context.
> Basically, I want to know if the following code will work:
>
> *buffer =100;
> while (*buffer == 100) {
> schedule();
> }
>
> What I want to know is whether the schedule() call will give CPU time to the simulator,
> which is running as a user-space process. When the simulator runs, it sees that the
> buffer has the value 100, and then it does some calculations, and writes a different value
> back to the buffer. This should cause "*buffer == 100" to become false.
>
What i saw is calling schedule in a loop of the kernel thread/process
makes it to use 99% of the CPU, if CPU is not doing other stuffs (and
might slow down the user space too as it has low priority then kernel
space) ... So my idea is to better use schedule_timeout with some
small value, so that load on the CPU will be less ........
--
Fawad Lateef
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
Fawad Lateef
>
> >
>
>> Yes, schedule() will certainly sends your driver to sleep and will
> >schedule it to run again; thus give certainly time to other
> >applications to work ...
>
>
> I think you mean the "process that called the driver will be put to
> sleep"...right??
>
> the driver itself doesn't have any process context.
>
Yes, You are right, writing " driver to sleep " I mean what ever
driver is doing in the current context (that will be the process
context) schedule will put process in which driver is running (as
driver functions are call-backed from the kernel in most cases) to
sleep !!!!