On 21/09/16(Wed) 16:29, David Gwynne wrote:
> the point i was trying to make was that the existing stuff (tasks, timeouts)
> can be used together to get the effect we want. my point was very poorly made
> i think your point is that you can make a clever change to timeouts and not
> have to do a ton of flow on code changes to take advantage of it.
I'm trying to fix one problem at a time.
> if timeouts are the way to schedule stuff to run in the future, then we're
> going to get head-of-line blocking problems. pending timeouts will end up
> stuck behind work that is waiting on an arbitrary lock, because there's an
> implicit single thread that will run them all. right now that is mitigated by
> timeouts being an interrupt context, we just dont put a lot of work like that
> in there right now.
Really? Is it worth than it is now with the KERNEL_LOCK()?
> the benefit of taskqs is that you explicitly steer work to threads that can
> sleep independently of each other. they lack being able to schedule work to
> run in the future though.
> it turns out it isnt that hard to make taskqs use a priority queue internally
> instead of a tailq. this allows you to specify that tasks get executed in the
> future (or right now, like the current behaviour) in an explicit thread (or
> pool of threads). it does mean a lot of changes to code thats using timeouts
> now though.
I agree with you, but these thoughts are IMHO too far ahead. Everything
is still serialized in our kernel.