By: rwessel (rwessel.delete@this.yahoo.com), October 14, 2021 7:07 pm
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on October 14, 2021 11:18 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on October 14, 2021 9:01 am wrote:
> > none (none.delete@this.none.com) on October 13, 2021 6:06 am wrote:
> > > Documentation is available: https://developer.arm.com/documentation/ddi0602/2021-09/Base-Instructions
> > >
> > > Instructions for memory copy are named CPY* and those for memory set are SET*.
> >
> >
> > One of the concerns raised in earlier discussions was moving
> > a running copy to a different core (possibly to
> > a different machine in a cluster, or such). It appears
> > this punts the problem of underlying different native
> > move sizes to the OS fixing up an exception if the parameters end up incorrectly aligned on the new core.
>
>
> No need to make it as overly complicated as that when this is easily addressed by either using the strictest
> alignment on both cores (i.e. align at what is best for the big core even if that's stricter than the
> little core needs) or by never moving an in progress copy to a core using different alignment.
While dealing with that on-die can be dealt with by just not putting two incompatible cores on a die, that leaves the intra-cluster and VM migration issues with obvious solution. You could demand that the cluster (or potential VM migration targets) all have the same specs in this regard, but that seems a bit painful. The instruction definitions appear to define exceptions for when things like that happen, and so fixing it up in software ought to be possible. Still a bit ugly.
> rwessel (rwessel.delete@this.yahoo.com) on October 14, 2021 9:01 am wrote:
> > none (none.delete@this.none.com) on October 13, 2021 6:06 am wrote:
> > > Documentation is available: https://developer.arm.com/documentation/ddi0602/2021-09/Base-Instructions
> > >
> > > Instructions for memory copy are named CPY* and those for memory set are SET*.
> >
> >
> > One of the concerns raised in earlier discussions was moving
> > a running copy to a different core (possibly to
> > a different machine in a cluster, or such). It appears
> > this punts the problem of underlying different native
> > move sizes to the OS fixing up an exception if the parameters end up incorrectly aligned on the new core.
>
>
> No need to make it as overly complicated as that when this is easily addressed by either using the strictest
> alignment on both cores (i.e. align at what is best for the big core even if that's stricter than the
> little core needs) or by never moving an in progress copy to a core using different alignment.
While dealing with that on-die can be dealt with by just not putting two incompatible cores on a die, that leaves the intra-cluster and VM migration issues with obvious solution. You could demand that the cluster (or potential VM migration targets) all have the same specs in this regard, but that seems a bit painful. The instruction definitions appear to define exceptions for when things like that happen, and so fixing it up in software ought to be possible. Still a bit ugly.