[lkml]   [2000]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: hardcoded HZ in hub.c
David Woodhouse wrote:
> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:47    [W:0.050 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site