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? 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". > > 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? > 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? > 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?
