By: Etienne (etienne_lorrain.delete@this.yahoo.fr), August 26, 2022 12:54 pm
Room: Moderated Discussions
rwessel (rwessel.delete@this.yahoo.com) on August 25, 2022 8:16 am wrote:
> Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 6:24 am wrote:
> > Anon (no.delete@this.spam.com) on August 25, 2022 5:25 am wrote:
> > > Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 1:54 am wrote:
> > > > Like "load cacheline on local L1 D-cache in exclusive mode and refuse to share that cacheline"?
> > > > At some point your request has to be cancelled, else all processing
> > > > may stop due to a bug or an AB - BA lockup by two cores.
> > > > At that point (cancel exclusive request) you want an exception?
> > > > I also imagine there would be a limit on the number of cachelines a core refuses to share...
> > >
> > > I don't know, what I expect from a hardware claiming to
> > > provide transactions is that, when I request something
> > > within the predefined limits defined by the hardware vendor
> > > to be done atomically it will be done atomically,
> > > I know this is hard and the bigger the transaction the harder it will be, not everything in life is easy.
> > >
> >
> > Maybe an interface like "mwait" but waiting that a (finite) list of data cachelines
> > (and few code cacheline covering code to be executed) are all available in exclusive
> > mode on the local core would be better then, probably with a timeout.
> > You would not be sure that such "wait" ever succeed without timeout, but if it does then
> > the transaction can start and will complete... unless you use absent cachelines.
> > Not sure how easy to implement in hardware, not sure how easy to use in software.
> > At least it would not waste resources, and the sibling core would have time to do its stuff.
>
>
> I'm not sure I understand this concern. The transaction appears (eventually) to all other cores
> as a single atomic event. In practice another transaction (or a non-transactional access) can interfere,
> and prevent completion, but they can't cause a deadlock. Worst case a "guaranteed" transaction eventually
> halts all other cores in the configuration while doing a couple of retries (one would hope that such
> an extreme measure would be quite rare, but it's a plausible last resort). Even a normal (non-guaranteed)
> transaction can use random backoff to increase the odds of success.
The point is not to start "work" on a core when it is already known it will not complete - stay in a single wait instruction which can be timed for optimization purpose, not to stop 30 cores when two cores are fighting each over (AB/BA)
And not limit to one single load/store pair on a single cacheline, but he generalise to few cachelines, be able to use in userspace.
Hardware to know not to schedule this sibling as long as those few cachelines are not held exclusively, and try harder and harder to get such lines, then have 100% success rate (unless software bug).
> Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 6:24 am wrote:
> > Anon (no.delete@this.spam.com) on August 25, 2022 5:25 am wrote:
> > > Etienne (etienne_lorrain.delete@this.yahoo.fr) on August 25, 2022 1:54 am wrote:
> > > > Like "load cacheline on local L1 D-cache in exclusive mode and refuse to share that cacheline"?
> > > > At some point your request has to be cancelled, else all processing
> > > > may stop due to a bug or an AB - BA lockup by two cores.
> > > > At that point (cancel exclusive request) you want an exception?
> > > > I also imagine there would be a limit on the number of cachelines a core refuses to share...
> > >
> > > I don't know, what I expect from a hardware claiming to
> > > provide transactions is that, when I request something
> > > within the predefined limits defined by the hardware vendor
> > > to be done atomically it will be done atomically,
> > > I know this is hard and the bigger the transaction the harder it will be, not everything in life is easy.
> > >
> >
> > Maybe an interface like "mwait" but waiting that a (finite) list of data cachelines
> > (and few code cacheline covering code to be executed) are all available in exclusive
> > mode on the local core would be better then, probably with a timeout.
> > You would not be sure that such "wait" ever succeed without timeout, but if it does then
> > the transaction can start and will complete... unless you use absent cachelines.
> > Not sure how easy to implement in hardware, not sure how easy to use in software.
> > At least it would not waste resources, and the sibling core would have time to do its stuff.
>
>
> I'm not sure I understand this concern. The transaction appears (eventually) to all other cores
> as a single atomic event. In practice another transaction (or a non-transactional access) can interfere,
> and prevent completion, but they can't cause a deadlock. Worst case a "guaranteed" transaction eventually
> halts all other cores in the configuration while doing a couple of retries (one would hope that such
> an extreme measure would be quite rare, but it's a plausible last resort). Even a normal (non-guaranteed)
> transaction can use random backoff to increase the odds of success.
The point is not to start "work" on a core when it is already known it will not complete - stay in a single wait instruction which can be timed for optimization purpose, not to stop 30 cores when two cores are fighting each over (AB/BA)
And not limit to one single load/store pair on a single cacheline, but he generalise to few cachelines, be able to use in userspace.
Hardware to know not to schedule this sibling as long as those few cachelines are not held exclusively, and try harder and harder to get such lines, then have 100% success rate (unless software bug).
