Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on October 1, 2021 7:55 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on October 1, 2021 5:10 am wrote:
> > > My latest theory is that all three instructions form a unit and if there is an interrupt the restart
> > > is at the first instruction.
>
> Alternatively they are using a real DMA which goes through the memory caches.
> The first instruction setup the DMA.
> The second instruction wait for the DMA to finish, and if interrupted pause that DMA so that
> the memory bus is not completely saturated while executing the interrupt treatment.
> The third instruction check if the DMA was finished, if not the second instruction
> was interrupted and needs to be re-executed (so jump backward one instruction).
> If the DMA is finished, then free/power down the DMA machinery.
>
> That has the advantage of not using registers, not copying in smaller unit than the cache line, so
> not needing to read the *destination* memory into the cache line - just in case the copy is interrupted.
> To repeat, if processor is interrupted, the end of the cache line has to be coherent, so has to be
> read from memory (processor doesn't know yet if it will be interrupted) before being written.
>
> The problem of interrupting a memcopy and then try to re-execute another memcopy from inside the interrupt
> treatment has to be solved by saving the exact state of the DMA in available registers.
>
> It is out of the question to re-read part of the source, or write twice
> the destination (after interrupt) in case of I/O or uncached memcopy.


You still either need to architect the (saved) state of the DMA engine, or you have trouble moving the running code to different cores after an interrupt (big/little, intra-cluster, VM migrations). And you now need the OS to save that additional state.