> On 19 Sep 2016, at 20:28, Mike Belopuhov <m...@belopuhov.com> wrote: > > On 19 September 2016 at 11:06, Martin Pieuchot <m...@openbsd.org> wrote: >> On 19/09/16(Mon) 13:47, David Gwynne wrote: >>> [...] >>> id rather not grow the timeout (or task for that matter) apis just >>> yet. theyre nice and straightforward to read and understand so far. >> >> So better introduce a new API, right?
i guess. 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 though. 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. >> >>> for this specific problem can we do a specific fix for it? the diff >>> below is equiv to the timeout_set_proc change, but implements it >>> by using explicit tasks that are called by the timeouts from a >>> common trampoline in the network stack. >> >> Is it really a specific problem? We already encounter this for the >> linkstate and the watchdog. >> >> I'm not convinced by this approach. I don't understand why: >> - adding a task in every data structure is worth it >> - introducing a new if_nettmo_* make things simpler >> >> So there's something which isn't explain in this email. >> >> And I'll bet that in the upcoming years we're going to stop using soft >> interrupts. Meaning that timeout handlers will always have a stack >> available. If/when this happens, it will be easier to do: >> >> s/timeout_set_proc/timeout_set/ >> > > FWIW, I agree with mpi on this. As a temporary change his > approach is sound. if its temporary, then fine. > I would also like to know what prevents us from executing all > timeouts in a thread context now? serial drivers with softtty > line discipline entanglement? theres some stuff in wi(4) and ipsec that would need to be fixed first. apart from that i have concerns a about having everything go through a single execution context. 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. 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. anyway. if this is temporary, then fine. dlg
