On Sun, Jan 12, 2020 at 12:52:53PM +0100, Martin Pieuchot wrote: > On 11/01/20(Sat) 16:12, Scott Cheloha wrote: > > On Sat, Jan 11, 2020 at 05:41:00PM +0100, Martin Pieuchot wrote: > > > Before converting network timeouts to run in a thread context they were > > > executed in a soft-interrupt handler. This design implied that timeouts > > > were serialized. > > > > Yep. > > > > > The current "softclock" thread runs on CPU0 to limit border effects due > > > to the conversion from soft-interrupt to thread context. > > > > Define "border effects". Do you mean limiting the delay between when > > softclock() yields and softclock_thread() runs? > > timeout_hardclock_update() is just executed by CPU0, right?
Yes, only on the primary CPU. > So aren't softclock handlers also executed on CPU0? If so, executing the > softclock only on CPU0 is a conservative approach. > > Whatever bug we could expose by running the handler on another CPU isn't > interesting for the moment. That's what I meant with "border effects". Gotcha, alright, sure. Makes sense. > > > However we should raise the IPL level of this thread to ensure no other > > > timeout can run in the middle of another one. > > > > This makes sense, though I have a few questions. Sorry in advance if > > some of this is obvious, my understanding of the "rules" governing the > > interrupt context is still limited. > > > > 1. If softclock() takes more than a full tick to complete and is > > interrupted by hardclock(9), which schedules another softclock(), > > but *before* softclock() returns it wakes up softclock_thread()... > > which of those will run first? > > > > The softclock() interrupt or the softclock_thread()? > > Why do you ask? Without this change we have a precedence: in the scenario I described the interrupt will always run before the thread. Now that they both run with the same IPL I am unsure as to which would run first. I assume the interrupt but I want to make sure because if the order is undefined we might be breaking stuff that depends upon it. > > 2. If both process and vanilla timeouts run at IPL_SOFTCLOCK, what > > really is the difference between them? Is there still a reason to > > distinguish between them? Would it make sense to run *all* timeouts > > from the softclock thread once we have a chance to fork it from > > process 0? > > As always is a matter of exposing and debugging the unknown problems > related to any change. So why would you like to change the existing? There was work a while ago to move all MI interrupts to dedicated threads. Near as I can tell the only one that wasn't moved was softclock(). So I look at this change and the shrinking difference between running timeouts from the interrupt context and running them from the thread and I have to ask: why not just eliminate the interrupt and run them all from the thread? > > 3. Is there a way to prioritize the softclock thread over other > > threads on the primary CPU so that the scheduler makes it runnable > > as soon as possible after softclock() returns to reduce latency? > > Why do you ask? If we could prioritize the timeout thread to run before others we could guarantee that it runs "soon after" the hardclock(9), removing one possible barrier to moving them to run from the thread. Again, I don't know whether this is possible, but I look at the move from interrupts to threads and now the change in IPL levels and question the need for an interrupt if we could do an equivalent job with a thread.
