Re: hardcoded HZ in hub.c

[Andrew Morton <andrewm@uow.edu.au>]

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/