From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CBF5C47076 for ; Fri, 21 May 2021 19:05:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 072A8613B6 for ; Fri, 21 May 2021 19:05:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234678AbhEUTGk (ORCPT ); Fri, 21 May 2021 15:06:40 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:55792 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237725AbhEUTGi (ORCPT ); Fri, 21 May 2021 15:06:38 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1621623913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SR6OQKV549q4JEmHXLaUA2oYN7XUebJWxPZZsjcwpXA=; b=Zv3ZMHsz/WqA2OZplcBOcXMjOU/yIE3KJx2qdGtwi23yV0Kv8Z05RG84DqldU3qTQsVscs wWviYdHkkDT2Gel7in/axP06urZjAtnqXmbHUJ4kgYfHtL7ThpT4G37dGJeXSTGpkMiG5G fUk1j9Jxc5SoaukIUVtfUQIvSDPoCMycxdIYXYUpfJxQUZC3HnDWrstt5DO96lPsmPzdrY d46LcFWDyNuOuCfJ6/fb5glFNG7YMIbP4bwwFE6tzJ2cc38+cX0Mci3Iye661ehz4B0CKt cxm8RR23b/vwDYFv+88Q4HewZYvABF4XLue/5SYTH8IO1m9oUjOcD+4npJa2gw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1621623913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SR6OQKV549q4JEmHXLaUA2oYN7XUebJWxPZZsjcwpXA=; b=KIQGYLB6834C1i8fuxGQgYAzy4USl9ZUZIDx704KQ4rHjuVYaBZxU70nTLv/D+Yu6NTMVY fu7haF6Uk4uH0pBw== To: Florian Weimer , Dave Hansen Cc: Dave Hansen via Libc-alpha , Len Brown , Rich Felker , Linux API , "Bae\, Chang Seok" , X86 ML , LKML , Kyle Huey , Borislav Petkov , Andy Lutomirski , Keno Fischer , Arjan van de Ven , Willy Tarreau Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features In-Reply-To: <87r1i06ow2.fsf@oldenburg.str.redhat.com> References: <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu> <20210415054713.GB6318@zn.tnic> <20210419141454.GE9093@zn.tnic> <20210419191539.GH9093@zn.tnic> <20210419215809.GJ9093@zn.tnic> <874kf11yoz.ffs@nanos.tec.linutronix.de> <87k0ntazyn.ffs@nanos.tec.linutronix.de> <37833625-3e6b-5d93-cc4d-26164d06a0c6@intel.com> <9c8138eb-3956-e897-ed4e-426bf6663c11@intel.com> <87pmxk87th.fsf@oldenburg.str.redhat.com> <939ec057-3851-d8fb-7b45-993fa07c4cb5@intel.com> <87r1i06ow2.fsf@oldenburg.str.redhat.com> Date: Fri, 21 May 2021 21:05:12 +0200 Message-ID: <87mtsnaown.ffs@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Fri, May 21 2021 at 18:19, Florian Weimer wrote: > * Dave Hansen: >> On 5/21/21 7:44 AM, Florian Weimer wrote: >>> Why can't userspace look at XCR0 to make the decision? >> >> The thing we're trying to avoid is a #NM exception from XFD (the new >> first-use detection feature) that occurs on the first use of AMX. >> XCR0 will have XCR0[AMX]=1, even if XFD is "armed" and ready to >> generate the #NM. > > I see. So essentially the hardware wants to offer transparent > initialize-on-use, but Linux does not seem to want to implement it this > way. The hardware offers an exception which can be used to implement that, but the hardware does not dictate that usage. If we'd go that way we lost any control over that resource and I can demonstrate with AVX512 today what kind of consequences that has with mixed criticality realtime workloads. The only solution we have today is to disable AVX512 completely, which sucks because restricted usage can be benefitial for some of the computations. The problem is that the approach of user space in general seems to be blindly_select_max(AVX). I've seen that in quite some places. With AMX (and the stuff coming next) we have the chance to do proper resource control and it would be outright stupid not to take that opportunity. Thanks, tglx