Hi, > what is the upper bound for interrupt latency?
There is no clear official upper bound. LoopStackCheckElisionReducer removes stack checks from loops that have less than kMaxIterForStackCheckRemoval (= 5000) iterations, but I chose that number fairly arbitrarily, using the "meh, sounds vaguely reasonable" principle (and it doesn't even take into account the number of instructions in the loop). Regarding your initial proposal (splitting loops into an inner loop without stack checks and an outer part with stack checks): if you can get that to work, sure, why not. Doesn't sound super easy to do, but why not. Also, once you've implemented that, we can reuse the analysis to improve our loop unrolling (which is currently very trivial: it repeats the whole loop header (including the condition) in between the unrolled iterations): we should then be able to remove the in-between condition checking. > The runtime patching certainly sounds interesting, if more complicated that a loop transform. I had no idea what you were talking about though :) but Pierre has filled me in. For the readers that don't have Pierre nearby to fill them in: What I meant is that when we emit loops, we could add a few nops before the backedge jump (remember that loops only have a single backedge in Turbofan/shaft). When we want to trigger an interrupt and the main thread is executing a loop, we could patch the nops in-place to instead either call a specific function or jump to a trampoline that would take care of processing the interrupt. Details would need to be ironed out: the nops might not even be necessary as we could maybe patch the backedge itself to jump to a trampoline within the Turboshaft code; how to patch back to the original code safely is also a good question, etc, etc. The benefit of patching compared to your proposal is that it can apply to every loop, without requiring an analysis pass in Turboshaft to figure out the general shape of the loop, like what is the loop condition & co, and without increasing the size of Turboshaft graphs (it might slightly increase the size of the generated code because of a few nops, but hopefully not much). > could we not just always have a probing load in the loop? Not quite sure what you mean by that. Do you mean a load from a memory region that we would protect when we want an interrupt to happen so that the load traps then and we would rely on the trap handler to process the interrupt request? If so: maybe, but that's still a load, which isn't great. Also, it's not entirely clear to me why stack checks are expensive. In theory, there are 1 load + 1 comparison + 1 branch, and the branch is easily branch predictable, so this whole thing should be free on superscalar out-of-order CPUs... Yet it definitely isn't. If the load is the expensive part, then we could only do the stack check every 5000 iterations or so (which still requires 1 comparison + 1 branch, to know whether we are in an iteration where we need to do a stack check). If it's the comparison + branch part, indeed a trapping load might be helpful. And if it's simply the combination of load+compare+branch, then either code patching or your idea of splitting the loop into inner loop + outer loop are the only options I can think of. If you have insights on what is expensive in stack checks, I'm all ears :) Cheers, Darius On Fri, 13 Jun 2025 at 13:41, Jakob Kummerow <[email protected]> wrote: > what is the upper bound for interrupt latency? If we have an inner loop, >> without calls, I would assume we could have a reasonable number of >> instructions and iterations before that latency would be adversely affected? >> > > Yes, interrupting doesn't need to be immediate. There are situations where > users can observe the latency of interrupting a long-running loop, so it > should be something that a human perceives as fast. To give numbers, I'd > aim for no more than 10ms latency on fast hardware, so that it won't be > more than 100ms on slow hardware. If an order of magnitude less than this > upper bound can be achieved without significant drawbacks, that's even > better. > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/CAKSzg3Rj%2Bk8GwTsECE-mRDWweU5g_kAHm1QV2_K%3DBkjmf4zAUQ%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAKSzg3Rj%2Bk8GwTsECE-mRDWweU5g_kAHm1QV2_K%3DBkjmf4zAUQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > Darius Mercadier Software Engineer [email protected] Google Germany GmbH Erika-Mann-Straße 33 80636 München Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAKRYUpt2-akyvZVEoxjO9uJq%2Bo9uUT8V7FmWP_v6tWe7g%2BiZ0g%40mail.gmail.com.
