Varun,
I think the main problem is this - and it's the only one I'm addressing
here.
You're assuming that when a process is waiting
with a poll(2) (effectively sleeping with a schedule_timeout with
TASK_INTERRUPTABLE), the only way it has of knowing that new data is
available is by checking when the *wait queue times out*, thus
equating it to a user-space poll in analysis.
All your analysis, as I understand is based on this assumption.
Inasmuch as this specific case is concerned, I agree with mostly everything
you have to say.
However, what I've been trying to say, and what precludes any such
analysis from the perspective of a userspace process, is that there are
situations, which occur *very* often in which the wakeup operation
occurs not when the wait_queue times out, but by some other activity in
the kernel that the process does not know about.
Take the tty drivers for instance. When writing to a line, the tty line
discipline sleeps on its waitqueue interruptably and waiting for a timeout,
and it checks if there is space available in the buffer when the queue
times out. However, this *very rarely* happens. What *actually* happens
is that someone clears up the write buffer (like a pty process, or the
serial interrupts BH) and *explicitly* wakes up the queue. Hostfs in UML
is another example of the same. The timeout values for such wait queues
are extremely large, because the kernel knoews someone or the other is
going to wake it up when it needs to be woken up.
And this is precisely what *user space* processes are clueless about. If
a user space process sleeps waiting for input on a tty line, it *cannot*
sleep in a state that's interruptable by a pty writing to or clearung up
a buffer. And this is what IMHO, eclipses any further analysis.
If you want data at regular intervals and not on demand, you will naturally
call sleep periodically and read. We were talking about the eff. of a
sleep in u-space vs. doing it in k-space.
// We seem to have two different definitions of "wakeup." I am refering to wakeup as
the mechanism that passes control back to the process after some condition. If I
understand correctly, you are refering to wakeup as the work involved in the process
regaining control and doing something thereafter.
Absolutely not. No, I don't refer to wakeup as "the work involved in the
process regaining control and doing something thereafter" :-). Good god!
// As per my definition, how can the kernel delegate the responsibility of the wakeup
to the process? The process cannot decide when it should be woken up, it only decides
when it should go to sleep, and under what conditions should it "request" the kernel
to wake it up.
Sorry if that's what I conveyed. If you're talking abt the first case,
take it literally - process sleeps, wakes up on timer, checks and goes
back to sleep.
// Even when you use sleep(), the kernel only wakes up the process, as per the
mechanism that I described - sleep() -> sys_nanosleep() ->
schedule_timeout(TASK_INTERRUPTIBLE) -> add_timer -> clock interrupt -> bottom half
processing -> schedulers sees if timeout has elapsed and wakes up the process, i.e.
pass control back to the process.
// The wakeup in this case is just as efficient in this case as any other syscall. The
difference is in what happens after the wakeup. In what you propose, the process would
be garuanteed to have some data to operate on - in my case, it might have to go back
to sleep. But, in any case, the wakeup operation from the kernel is equally efficient,
both involve the scheduler decieding to run the process.
I agree wholeheartedly, but only if you make that initial assumption.
// > A look at how the line ptys, serial drivers etc. wake up the line discipline
// > wait_queues in pty.c, tty_io.c and n_tty.c should give a better idea about what
// > I'm saying.
//
// A look at how sleep() is implemented in Linux should give a better idea about what
I am what I'm saying.
[this is also crucial, so correct me if I'm wrong-]
You're saying that sleep outside the kernel and in the kernel are one and
the same thing and can do the same thing. I'm saying they're not.
Sleep outside the kernel *cannot* wait in a state interruptable by an
event that is *internal* to the kernel. And such events are crucial in
wakeup operations (cliched now - pty unthrottle, hostfs data_in, ldisc
wakeup).
// As you can see, these are design issues and my point is that whether polling or
interrupt driven operation is more efficient is dependent on the application on hand.
Cool. No debate here.
// What we have been discussing here is differences in implementation of a specific
task - should you poll or should you be interrupted. What should be used is very
specific to the application at hand. You can't have a carte blanch and say the
"polling is always inefficient" - if used properly, and under the right circumstances,
polling can be more efficient the interrupt driven operations - and all of this has
nothing to do with how the kernel wakes up the process - it's do with what happens
before/after the wakeup.
Good again.
// > updated procmail. thanks
//
// Liar! People, I'll have you know that I sent him those pictures anyway, and he,
unfortuanately, liked them and is asking for more. This time around though, I am going
to send him naked pictures of ..er..Saddam Hussain.
I was very pleased to discover that they weren't as bad as I'd imagined.
In fact they were cute. People, Varun's actually a Hamster! Makes sense
now that you think about it doesn't it?
I particularly liked the "lazing in the mouse cradle", and "my coworker
sat on me" shots... I wonder what this Saddan Hussain character really is.
I've heard Bill Gates is an anteater. Send me shots of him instead?
Squeakingly yours,
Sapan
// Regards,
// -Varun
// --
// ---------------------------------------
// Mindframe Software & Services Pvt. Ltd.
//
// http://www.mindsw.com
// ---------------------------------------
//
// ================================================
// To subscribe, send email to [EMAIL PROTECTED] with subscribe in subject header
// To unsubscribe, send email to [EMAIL PROTECTED] with unsubscribe in subject
header
// Archives are available at http://www.mail-archive.com/ilugd%40wpaa.org
// =================================================
//
================================================
To subscribe, send email to [EMAIL PROTECTED] with subscribe in subject header
To unsubscribe, send email to [EMAIL PROTECTED] with unsubscribe in subject header
Archives are available at http://www.mail-archive.com/ilugd%40wpaa.org
=================================================
