linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Revisiting XFD-based AMX and heterogenous systems
@ 2021-11-15 19:59 Andy Lutomirski
  2021-11-15 20:11 ` Arjan van de Ven
  2021-11-15 21:12 ` Thomas Gleixner
  0 siblings, 2 replies; 5+ messages in thread
From: Andy Lutomirski @ 2021-11-15 19:59 UTC (permalink / raw)
  To: Asit K Mallick, Dave Hansen, Brown, Len, Thomas Gleixner,
	Peter Zijlstra (Intel),
	the arch/x86 maintainers, Borislav Petkov,
	Linux Kernel Mailing List, Bae, Chang Seok, Arjan van de Ven
  Cc: Andrew Cooper

[resend -- first try was HTML.  oops.]

Hi all-

I just learned that current Alder Lake review samples are actually heterogenous, at least physically.  The performance cores have AVX-512 and the efficiency cores don't have AVX-512.  Since no OS supports actual runtime ISA heterogeneity, this feature seems to be hidden in that one must choose, per boot, whether one wants AVX-512 or efficiency cores, but the CPU is physically heterogenous.

All the earlier discussions about Linux AMX architecture happened under the assumption that xfeature-heterogenous systems would never happen, and my grudging acceptance of the XFD model was predicated on that.  But now we have obviously heterogenous hardware that is apparently actually shipping at least to reviewers, and I think we should revisit this before we merge AMX support.

The current proposed AMX ABI on Linux has all tasks starting out with the AMX bits set in XCR0.  If the tasks want to actually use AMX, they need to issue a prctl asking for permission and, if they don't issue that prctl, they will take XFD faults and get signalled if they try to use the TILE regs.  If Intel thinks we might ever have software-visible heterogenous system, then this will be very awkward -- all tasks will start with AMX set in XCR0 even if they're on efficiency cores and even they have no intention to ever use AMX.  Once a process asks for AMX permission or perhaps after the first XFD fault, the process will be pinned to performance cores and can use AMX.  Aside from awkwardness, this requires that efficienty cores actually implement enough of AMX to do this.  And keep in mind that Alder Lake is actually heterogenous for AVX-512, and there is no such thing as AVX-512 XFD.

So I suggest that we go back and switch to the XCR0 model.  Tasks will start out with AMX clear in XCR0.  If they want AMX, they issue a prctl asking for AMX, AMX gets set in XCR0, and the tasks need to be able to tolerate the XCR0 change.  Then, if Intel ever wants to expose the full Alder Lake physical capabilities and support efficiency cores and AVX-512 on the same boot, we can have a mode in which tasks start with AVX-512 clear in XCR0 and can opt in with prctl.  This will require HPC-like apps to be recompiled or run with a special wrapper bit will otherwise expose the full HW capabilities. (Of course this assumes that Intel sets up MSRs or ucode or whatever to support this.)

What do you all think?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Revisiting XFD-based AMX and heterogenous systems
  2021-11-15 19:59 Revisiting XFD-based AMX and heterogenous systems Andy Lutomirski
@ 2021-11-15 20:11 ` Arjan van de Ven
  2021-11-15 20:18   ` Andy Lutomirski
  2021-11-15 21:12 ` Thomas Gleixner
  1 sibling, 1 reply; 5+ messages in thread
From: Arjan van de Ven @ 2021-11-15 20:11 UTC (permalink / raw)
  To: Andy Lutomirski, Asit K Mallick, Dave Hansen, Brown, Len,
	Thomas Gleixner, Peter Zijlstra (Intel),
	the arch/x86 maintainers, Borislav Petkov,
	Linux Kernel Mailing List, Bae, Chang Seok
  Cc: Andrew Cooper

On 11/15/2021 11:59 AM, Andy Lutomirski wrote:
> [resend -- first try was HTML.  oops.]
> 
> Hi all-
> 
> I just learned that current Alder Lake review samples are actually heterogenous, at least physically.  The performance cores have AVX-512 and the efficiency cores don't have AVX-512.  Since no OS supports actual runtime ISA heterogeneity, this feature seems to be hidden in that one must choose, per boot, whether one wants AVX-512 or efficiency cores, but the CPU is physically heterogenous.
> 
> All the earlier discussions about Linux AMX architecture happened under the assumption that xfeature-heterogenous systems would never happen, and my grudging acceptance of the XFD model was predicated on that.  But now we have obviously heterogenous hardware that is apparently actually shipping at least to reviewers, and I think we should revisit this before we merge AMX support.
> 

Alderlake is not heterogenous.
This is not just an "OS can deal with it" thing... it's throughout everything from low lower power delivery through bios through ...

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Revisiting XFD-based AMX and heterogenous systems
  2021-11-15 20:11 ` Arjan van de Ven
@ 2021-11-15 20:18   ` Andy Lutomirski
  2021-11-23 14:24     ` Len Brown
  0 siblings, 1 reply; 5+ messages in thread
From: Andy Lutomirski @ 2021-11-15 20:18 UTC (permalink / raw)
  To: Arjan van de Ven, Asit K Mallick, Dave Hansen, Brown, Len,
	Thomas Gleixner, Peter Zijlstra (Intel),
	the arch/x86 maintainers, Borislav Petkov,
	Linux Kernel Mailing List, Bae, Chang Seok
  Cc: Andrew Cooper



On Mon, Nov 15, 2021, at 12:11 PM, Arjan van de Ven wrote:
> On 11/15/2021 11:59 AM, Andy Lutomirski wrote:
>> [resend -- first try was HTML.  oops.]
>> 
>> Hi all-
>> 
>> I just learned that current Alder Lake review samples are actually heterogenous, at least physically.  The performance cores have AVX-512 and the efficiency cores don't have AVX-512.  Since no OS supports actual runtime ISA heterogeneity, this feature seems to be hidden in that one must choose, per boot, whether one wants AVX-512 or efficiency cores, but the CPU is physically heterogenous.
>> 
>> All the earlier discussions about Linux AMX architecture happened under the assumption that xfeature-heterogenous systems would never happen, and my grudging acceptance of the XFD model was predicated on that.  But now we have obviously heterogenous hardware that is apparently actually shipping at least to reviewers, and I think we should revisit this before we merge AMX support.
>> 
>
> Alderlake is not heterogenous.
> This is not just an "OS can deal with it" thing... it's throughout 
> everything from low lower power delivery through bios through ...

Sure, but I bet the demand will be there.  The desktop gamer types will flip off E cores and flip on AVX512 and call it a day.  But the ones who want battery life will be annoyed, and I bet someone at Intel is contemplating how to switch it at runtime.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Revisiting XFD-based AMX and heterogenous systems
  2021-11-15 19:59 Revisiting XFD-based AMX and heterogenous systems Andy Lutomirski
  2021-11-15 20:11 ` Arjan van de Ven
@ 2021-11-15 21:12 ` Thomas Gleixner
  1 sibling, 0 replies; 5+ messages in thread
From: Thomas Gleixner @ 2021-11-15 21:12 UTC (permalink / raw)
  To: Andy Lutomirski, Asit K Mallick, Dave Hansen, Brown, Len,
	Peter Zijlstra (Intel),
	the arch/x86 maintainers, Borislav Petkov,
	Linux Kernel Mailing List, Bae, Chang Seok, Arjan van de Ven
  Cc: Andrew Cooper

Andy,

On Mon, Nov 15 2021 at 11:59, Andy Lutomirski wrote:
> So I suggest that we go back and switch to the XCR0 model.  Tasks will
> start out with AMX clear in XCR0.  If they want AMX, they issue a
> prctl asking for AMX, AMX gets set in XCR0, and the tasks need to be
> able to tolerate the XCR0 change.

We can do that, but that still want's XFD for avoiding allocating large
buffers for all tasks in such a process which never use that feature.

Aside of that as we all know context switching XCR0 sucks.

> Then, if Intel ever wants to expose the full Alder Lake physical
> capabilities and support efficiency cores and AVX-512 on the same
> boot, we can have a mode in which tasks start with AVX-512 clear in
> XCR0 and can opt in with prctl.  This will require HPC-like apps to be
> recompiled or run with a special wrapper bit will otherwise expose the
> full HW capabilities. (Of course this assumes that Intel sets up MSRs
> or ucode or whatever to support this.)

If software needs to be recompiled or wrapped anyway then Intel can just
provide XFD support for AVX512 if it wants to expose this at runtime on
those CPUs.

As that needs to be implemented for AMX anyway the logical consequence
for user space is:

    available = arch_prctl(ARCH_GET_XCOMP_SUPP);        // Same as XCR0
    permitted = arch_prctl(ARCH_GET_XCOMP_PERM);        // XRC0 & permission bits

and work from there. If done with future XFD support for other features
than AMX in mind (even retroactively added for AVX512) then this should
be straight forward to adjust.

For the kernel adding XFD for AVX512 even conditionally based on a CPUID
bit is pretty straight forward now. It needs a small change to the way
how we distinguish XFD based and unconditional features, but that's
trivial effort compared to going for XCR0 switching with all its
downsides.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Revisiting XFD-based AMX and heterogenous systems
  2021-11-15 20:18   ` Andy Lutomirski
@ 2021-11-23 14:24     ` Len Brown
  0 siblings, 0 replies; 5+ messages in thread
From: Len Brown @ 2021-11-23 14:24 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Arjan van de Ven, Asit K Mallick, Dave Hansen, Brown, Len,
	Thomas Gleixner, Peter Zijlstra (Intel),
	the arch/x86 maintainers, Borislav Petkov,
	Linux Kernel Mailing List, Bae, Chang Seok, Andrew Cooper

On Tue, Nov 16, 2021 at 1:22 AM Andy Lutomirski <luto@kernel.org> wrote:

> Sure, but I bet the demand will be there.  The desktop gamer types will flip off E cores and flip on AVX512 and call it a day.  But the ones who want battery life will be annoyed, and I bet someone at Intel is contemplating how to switch it at runtime.

The premise of this thread is erroneous.
See Arjan's response.


-- 
Len Brown, Intel Open Source Technology Center

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-11-23 14:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-15 19:59 Revisiting XFD-based AMX and heterogenous systems Andy Lutomirski
2021-11-15 20:11 ` Arjan van de Ven
2021-11-15 20:18   ` Andy Lutomirski
2021-11-23 14:24     ` Len Brown
2021-11-15 21:12 ` Thomas Gleixner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).