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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 71BB9C11F65 for ; Wed, 30 Jun 2021 13:59:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 53EC261437 for ; Wed, 30 Jun 2021 13:59:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235746AbhF3OB2 (ORCPT ); Wed, 30 Jun 2021 10:01:28 -0400 Received: from mga17.intel.com ([192.55.52.151]:33469 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234935AbhF3OAq (ORCPT ); Wed, 30 Jun 2021 10:00:46 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10030"; a="188729655" X-IronPort-AV: E=Sophos;i="5.83,312,1616482800"; d="scan'208";a="188729655" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2021 06:55:54 -0700 X-IronPort-AV: E=Sophos;i="5.83,312,1616482800"; d="scan'208";a="641716350" Received: from vkodithy-mobl.amr.corp.intel.com (HELO [10.209.94.253]) ([10.209.94.253]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jun 2021 06:55:53 -0700 Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: "Enrico Weigelt, metux IT consult" , Florian Weimer Cc: Len Brown , Peter Zijlstra , Dave Hansen via Libc-alpha , Dave Hansen , Rich Felker , Linux API , "Bae, Chang Seok" , X86 ML , LKML , Kyle Huey , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Keno Fischer , Willy Tarreau References: <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> <87wnqkzklg.fsf@oldenburg.str.redhat.com> <93e3b500-5992-a674-18e6-445d1db7b1f0@metux.net> <87tulirw5y.fsf@oldenburg.str.redhat.com> <84be3cfd-e825-ae75-bbae-2bbd3360daa7@metux.net> From: Arjan van de Ven Message-ID: <0978e79c-33ad-c05b-3897-99334c381396@linux.intel.com> Date: Wed, 30 Jun 2021 06:55:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <84be3cfd-e825-ae75-bbae-2bbd3360daa7@metux.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On 6/30/2021 5:22 AM, Enrico Weigelt, metux IT consult wrote: >> >> AMX will be shown as enabled in the hardware, but trap into the kernel >> on first use.  The kernel developers prefer a model where it is checked >> that the process has previously enabled the feature explicitly, instead >> relying on lazy initialization as part of the trap (as intended by the >> hardware design).  This means that the usual CPUID/XCR0 approach (which >> is reflected in the glibc feature) will not work. > > Ah, now I'm beginning to get it: > > * this feature needs to be initialized first, before it can be used > * on first use (when not initialized yet), it traps into the kernel > * we don't want to always initialize it at boot > > Correct ? not really, the init is PER PROCESS and then there is a per thread 8Kb state allocation that needs to be context switched/etc once you actually use AMX. > > What I'm wondering: why shall the process explicitly ask for it and > why isn't the initialization be done either on bootup or on first use ? the kernel needs to be able to say "no" in a graceful way, there are several scenarios (from the sysadmin wanting to manage power/performance/resources to outright compatibility where the kernel wants or needs to say "no". Most obvious example: if a process asked for an sigaltstack, we can't let the process use AMX since that stack will be too small most likely to hold the stackframe) If you do this on "first use of the instruction" there is no graceful way to say "no".