Date: Mon, 10 Feb 2020 23:17:45 -0800
On Monday, 10 February 2020 08:53:28 PST Andrey Semashev via Std-Discussion
wrote:
> > Is there any wording we can add to ask implementations to increase
> > alignment so that it is lock-free? Or is it a QoI?
>
> I did not find one, therefore my confusion.
Sorry, rephrasing: can you come up with the wording so that the
required_alignment is suitabe for lock_free operations?
> > No, atomicity is guaranteed on x86 by the hardware, though with extremely
> > poor performance, hence the suggestion to shoot with extreme prejudice.
> > The very newest processors announced by Intel have a "Split Lock
> > Detection" feature, which is not enabled by default and will cause a HW
> > exception like you describe. What you're describing is a future feature,
> > not current and past behaviour.
> >
> > The Linux kernel does not implement a CAS emulation and from what I
> > understand from my colleagues, it doesn't want to.
>
> My understanding is that split lock detection allows the kernel to
> handle the misaligned atomic operation. However, AFAIK, the requirement
> for alignment has always been there, as documented in SDM. Older
> processors simply crash with GP exception on alignment violation.
It depends on what instruction we're talking about. As you've discovered,
CMPXCHG16B does enforce a 16-byte alignment. And since it's the only 16-byte
atomic instruction, any 16-byte atomic operation on x86-64 requires the
alignment. Any other access will simply #GP(0).
But this does not apply to other instructions. For all others, the HW does and
has always done (since at least i386) unaligned atomic operations, silently.
The new thing is that Ice Lake Server and Tiger Lake can detect the situation
and trap with an #AC (not #GP(0)).
That's the same trap as would be produced by enabling the AC bit in the EFLAGS
register. But since that flag applies to all accesses, not just atomic, so no
one ever sets it. The CLAC and STAC instructions are basically unused, so they
got repurposed for SMAP a few years ago. The new setting applies only to
atomic accesses and cannot be disabled by user space.
In any case, CMPXCHG16B is a good example. We want that
atomic_ref<16bytes>::required_alignment be 16 on x86-64.
wrote:
> > Is there any wording we can add to ask implementations to increase
> > alignment so that it is lock-free? Or is it a QoI?
>
> I did not find one, therefore my confusion.
Sorry, rephrasing: can you come up with the wording so that the
required_alignment is suitabe for lock_free operations?
> > No, atomicity is guaranteed on x86 by the hardware, though with extremely
> > poor performance, hence the suggestion to shoot with extreme prejudice.
> > The very newest processors announced by Intel have a "Split Lock
> > Detection" feature, which is not enabled by default and will cause a HW
> > exception like you describe. What you're describing is a future feature,
> > not current and past behaviour.
> >
> > The Linux kernel does not implement a CAS emulation and from what I
> > understand from my colleagues, it doesn't want to.
>
> My understanding is that split lock detection allows the kernel to
> handle the misaligned atomic operation. However, AFAIK, the requirement
> for alignment has always been there, as documented in SDM. Older
> processors simply crash with GP exception on alignment violation.
It depends on what instruction we're talking about. As you've discovered,
CMPXCHG16B does enforce a 16-byte alignment. And since it's the only 16-byte
atomic instruction, any 16-byte atomic operation on x86-64 requires the
alignment. Any other access will simply #GP(0).
But this does not apply to other instructions. For all others, the HW does and
has always done (since at least i386) unaligned atomic operations, silently.
The new thing is that Ice Lake Server and Tiger Lake can detect the situation
and trap with an #AC (not #GP(0)).
That's the same trap as would be produced by enabling the AC bit in the EFLAGS
register. But since that flag applies to all accesses, not just atomic, so no
one ever sets it. The CLAC and STAC instructions are basically unused, so they
got repurposed for SMAP a few years ago. The new setting applies only to
atomic accesses and cannot be disabled by user space.
In any case, CMPXCHG16B is a good example. We want that
atomic_ref<16bytes>::required_alignment be 16 on x86-64.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel System Software Products
Received on 2020-02-11 01:20:25