Messages in this thread |  | | Date | Wed, 22 Nov 2000 22:34:55 +1100 | From | Andrew Morton <> | Subject | Re: hardcoded HZ in hub.c |
| |
David Woodhouse wrote: > > andrewm@uow.edu.au said: > > Nothing which sleeps for very long - mainly serial drivers which > > queue a call to tty_hangup(), which immediately queues _another_ > > tq_scheduler call to do_tty_hangup (Why? Heaven knows). > > Not so much worried about that. More about how sensitive they would be to > something _else_ causing the eventd thread to sleep for 'multiple seconds' > before getting round to doing what they asked.
Ah. No, I don't think it would be polite to cause TTY hangup processing to be deferred for this long. I'd suggest that the policy be "scheduled tasks can't sleep". I guess kmalloc(GFP_KERNEL) is acceptable because the system is already running like a dog if this sleeps.
> I really don't want to have to start using multiple eventd threads before > 2.5, if at all. So I don't want to add the USB hub stuff unless the other > queued tasks will be happy with that.
Some of these requirements could also be satisfied with a combination of a timer_list and a tq_struct. When the timer fires, feed the tq_struct into schedule_task.
Easy, except for the problem of killing the damn things off reliably. That would require a bit of infrastructure. But it's the right thing for netdriver media polling functions, for example. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |