On 12/01/20(Sun) 16:29, Scott Cheloha wrote: > On Sun, Jan 12, 2020 at 12:52:53PM +0100, Martin Pieuchot wrote: > [...] > > > > 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.
I understand the current behavior differently. Without this change the soft-interrupt might run in-between 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. The soft-interrupt always run first because it schedules the thread, see the wakeup() at the end of softclock(). > > > 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. Why? You give conclusion but don't explain why they would be needed. What code is broken? Isn't the current behavior fine? I don't understand why you want to change something here.
