From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by sourceware.org (Postfix) with ESMTPS id 69BFB3857C52 for ; Fri, 16 Apr 2021 22:05:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 69BFB3857C52 Received: by mail-ed1-f49.google.com with SMTP id g17so33276953edm.6 for ; Fri, 16 Apr 2021 15:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pE+1y3kVswoYX2AiLRaqMZxwYcgmWgUuY2qO0xxCCr0=; b=t4ic7ArTzZREQj8NwdBJcT73tC8BPDO9CzcnOgfUyjVXFCC1mBc8IScM55YBWYDGY4 lPfCbULa3KfGeBsHaEv/LfLaXPs9iqUWGv8WElqUuhg9P66Rqe3VYjudZqAcryN9otyL KQr/B68yZ0kggVmFosP/VGSQ/cq8Ny8rmLnDeqMKjdHP3Sl4+2S0zPdzqq45EgOBCC95 TQtqiIZ8/6LoRfgFi0yi51qCLMSJVKOkIwJPC9/9VNkwli4qyYDoA5QXP2DVl3fP1CkA /MvyHf6vi2K6nOnrfcnB3TBeqVk9ijh+jcZ/QJgFUOVAH5bGyhmoxH4suvbUQV/1PzgF Qcrw== X-Gm-Message-State: AOAM5327FXBfm3sSlYZzaSRyvo7YRSO4YHHE5k+D0BEZH4jZoxNVjlxZ nG/KNtB5xpgmQ55t8Hw5EYCiXkKXdo+wwn1mokQ= X-Google-Smtp-Source: ABdhPJyoUO+HJ3qMNcryPvKppffY+ChU86bnFi8SAvERKyhwOEbczCIePADySBwPpz3QZH93R58c6wfdllohe6bgSsE= X-Received: by 2002:aa7:cb97:: with SMTP id r23mr12279313edt.106.1618610722450; Fri, 16 Apr 2021 15:05:22 -0700 (PDT) MIME-Version: 1.0 References: <87lf9nk2ku.fsf@oldenburg.str.redhat.com> <20210413034346.GA22861@1wt.eu> <20210414095804.GB10709@zn.tnic> <20210415044258.GA6318@zn.tnic> <20210415052938.GA2325@1wt.eu> <20210415054713.GB6318@zn.tnic> In-Reply-To: <20210415054713.GB6318@zn.tnic> From: Len Brown Date: Fri, 16 Apr 2021 18:05:10 -0400 Message-ID: Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: Borislav Petkov Cc: Willy Tarreau , Andy Lutomirski , Florian Weimer , "Bae, Chang Seok" , Dave Hansen , X86 ML , LKML , linux-abi@vger.kernel.org, "libc-alpha@sourceware.org" , Rich Felker , Kyle Huey , Keno Fischer Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 22:05:30 -0000 On Thu, Apr 15, 2021 at 1:47 AM Borislav Petkov wrote: > What I'd like to see is 0-overhead for current use cases and only > overhead for those who want to use it. If that can't be done > automagically, then users should request it explicitly. So basically you > blow up the xsave buffer only for processes which want to do AMX. Indeed, expanding the xsave buffer happens only for tasks that touch AMX TILE registers. > And this brings the question about libraries which, if they start using > AMX by default - which doesn't sound like they will want to because AMX > reportedly will have only a limited? set of users - if libraries start > using it by default, then it better be worth the handling of the 8kb > buffer per process. I'm not aware of any intent to transparently use AMX for bcopy, like what happened with AVX-512. (didn't they undo that mistake?) > If not, this should also be requestable per process so that a simple > pipe in Linux: > > | grep | awk | sed ... > > and so on is not penalized to allocate and handle by default 8kb for > *each* process' buffer in that pipe just because each is linking against > glibc which has detected AMX support in CPUID and is using it too for > some weird reason like some microbenchmark saying so. Tasks are created without an 8KB AMX buffer. Tasks have to actually touch the AMX TILE registers for us to allocate one for them. > But my initial question was on the "establishing" part and was asking > where we have established anything wrt AMX. The patch set on LKML establishes working AMX Linux support in public. I am thankful for your and other public review and feedback on that series. I can think of 3 actual bugs that were found in the process. thanks, Len Brown Intel Open Source Technology Center