Re: Microarchitectural support for counting

On 12/25/24 1:30 PM, MitchAlsup1 wrote:

On Wed, 25 Dec 2024 17:50:12 +0000, Paul A. Clayton wrote:
 

On 10/5/24 11:11 AM, EricP wrote:

MitchAlsup1 wrote:

[snip]

--------------------------

>

But voiding doesn't look like it works for exceptions or conflicting
interrupt priority adjustments. In those cases purging the interrupt
handler and rejecting the hand-off looks like the only option.

>
Should exceptions always have priority? It seems to me that if a
thread is low enough priority to be interrupted, it is low enough
priority to have its exception processing interrupted/delayed.

 It depends on what you mean::
 a) if you mean that exceptions are prioritized and the highest
priority exception is the one taken, then OK you are working
in an ISA that has multiple exceptions per instruction. Most
RISC ISAs do not have this property.

The context was any exception taking priority over an interrupt
that was accepted, at least on a speculative path. I.e., the
statement would have been more complete as "Should exceptions
always (or ever) have priority over an accepted interrupt?"

b) if you mean that exceptions take priority over non-exception
instruction streaming, well that is what exceptions ARE. In these
cases, the exception handler inherits the priority of the instruction
stream that raised it--but that is NOT assigning a priority to the
exception.

Yes, if the architecture has precise exceptions.
I do not see much benefit from continuing execution along even
part of the non-exception instruction stream. There might be a
class of exceptions which are more "monitoring" exceptions
(something vaguely like event counters?) that do not need to be
precise in all visible state. Completing an atomic event (in
the normal instruction stream) _might_ make sense rather than
delaying and possibly failing (if optimistic) the atomic event.
There _might_ be some cases where an external thread activation
might be somewhat timing critical and not dependent on any
action performed by the exception handler. (I cannot think of
any case, but that may be a lack of imagination.)
Perhaps if execution is divided into tasks, an exception within
a task might restart the entire task after the exception handling,
pause the task during the handling of the exception, or complete
the task possibly running the exception handling in a parallel
thread. Even partial task completion, i.e., marking the task
done even though the result is not complete, might be appropriate
for some failures.
I guess I am thinking that any delay or elimination of some
computation from an exception may not necessarily have to delay
or break data flow at a higher level. Managing this seems likely
to be difficult. Debugging software would likely be even more
difficult.

c) and then there are the cases where a PageFault from GuestOS
page tables is serviced by GuestOS, while a PageFault from
HyperVisor page tables is serviced by HyperVisor. You could
assert that HV has higher priority than GuestOS, but it is
more like HV has privilege over GuestOS while running at the
same priority level.
 

(There might be cases where normal operation allows deadlines to
be met with lower priority and unusual extended operation requires
high priority/resource allocation. Boosting the priority/resource
budget of a thread/task to meet deadlines seems likely to make
system-level reasoning more difficult. It seems one could also
create an inflationary spiral.)
>
With substantial support for Switch-on-Event MultiThreading, it
is conceivable that a lower priority interrupt could be held
"resident" after being interrupted by a higher priority interrupt.

 I don't know what you mean by 'resident' would "lower priority
ISR gets pushed on stack to allow higher priority ISR to run"
qualify as 'resident' ?

"resident" was a vague term to mean low overhead of switching
back. Saving state to cache even with 64-byte per cycle bandwidth
might still be slower than another mechanism and cached data
might be evicted from L1, substantially increasing the latency.

 And then there is the slightly easier case: where GuestOS is
servicing an interrupt and ISR takes a PageFault in Hyper-
Visor page tables. HV PF ISR fixes GuestOS ISR PF, and returns
to interrupted interrupt handler. Here, even an instruction
stream incapable (IE & EE=OFF) of taking an Exception takes an
Exception to a different privilege level.
 Switch-on-Event helps but is not necessary.
 

A chunked ROB could support such, but it is not clear that such
is desirable even ignoring complexity factors.
>
Being able to overlap latency of a memory-mapped I/O access (or
other slow access) with execution of another thread seems
attractive and even an interrupt handler with few instructions
might have significant run time. Since interrupt blocking is
used to avoid core-localized resource contention, software would
have to know about such SoEMT.

 It may take 10,000 cycles to read an I/O control register way
down the PCIe tree, the ISR reads several of these registers,
and constructs a data-structure to be processed by softIRQ (or
DPC) at lower priority. So, allowing the long cycle MMI/O LDs
to overlap with ISR thread setup is advantageous.
 

(Interrupts seem similar to certain server software threads in
having lower ILP from control dependencies and more frequent high
latency operations, which hints that multithreading may be
desirable.)

 Sooner or later an ISR has to actually deal with the MMI/O
control registers associated with the <ahem> interrupt.

Yes, but multithreading could hide some of those latencies in
terms of throughput.