By: Doug S (foo.delete@this.bar.bar), October 1, 2021 11:17 am
Room: Moderated Discussions
rwessel (rwessel.delete@this.yahoo.com) on October 1, 2021 8:14 am wrote:
> 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.
The '!' notation on ARM means the registers for these new opcodes are modified, right? There are more bits in the registers than are needed to represent an address, at least until we get hardware with 64 bit VA though tags and PAC may conflict. The 'length' argument does not have this problem. It is probably bounded in some way - if 2^32-1 is the largest size it supports that leaves 32 unused bits, plenty of room for other state to be saved.
> 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.
The '!' notation on ARM means the registers for these new opcodes are modified, right? There are more bits in the registers than are needed to represent an address, at least until we get hardware with 64 bit VA though tags and PAC may conflict. The 'length' argument does not have this problem. It is probably bounded in some way - if 2^32-1 is the largest size it supports that leaves 32 unused bits, plenty of room for other state to be saved.
