Messages in this thread | | | Date | Wed, 27 Jan 1999 10:09:38 +0000 | From | Neil Conway <> | Subject | Re: [PATCH] Assorted counter/sched stuff |
| |
MOLNAR Ingo wrote: > > On Tue, 26 Jan 1999, Neil Conway wrote: > > > This is a collection of two types of fix: (a) drivers doing > > "current->counter =0;schedule()" with TASK_INTERRUPTIBLE set; [...] > > is this really a problem? It's a way to 'give up' the timeslice > voluntarily. (so it will be kindof lowprio when it gets RUNNING again)
Well, that's not quite the way I interpret it: the process simply won't run AT ALL again until all jobs in the run-queue have finished their time-slices (unless my brain's going).
And, certainly the one I fixed last month (in tty_ioctl.c/tty_wait_until_sent()) was a REAL problem. It was causing tcsh on loaded SMP machines to go to the back of the queue for CPU time basically every time you pressed "enter". This means 200ms delay * (loadavg/Ncpus) each time.
(It does depend though on why you were scheduling in the first place.)
When I first saw the problem in tty_ioctl.c, Linus said that because the driver was setting TASK_INTERRUPTIBLE it will not get the CPU back anyway (until the wait queue responds in that particular case). In the cases I have just changed, the driver won't get the CPU back until the timeout expires in schedule_timeout(). Once the timeout expires, why on earth would we want the driver to be low-priority? I'm not saying that's impossible, just that I don't see a reason - do feel encouraged to put me straight ;-)
I have to admit though that I don't even use any of the drivers I have patched so I can't say I've had a problem with them (!).
Neil
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |