From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by sourceware.org (Postfix) with ESMTPS id E67363949D80 for ; Tue, 13 Apr 2021 20:16:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E67363949D80 Received: by mail.kernel.org (Postfix) with ESMTPSA id 111DB613D4 for ; Tue, 13 Apr 2021 20:16:40 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id g17so20169541edm.6 for ; Tue, 13 Apr 2021 13:16:39 -0700 (PDT) X-Gm-Message-State: AOAM532U/xjyBOO6L3eRH814v5D5zPDpGrBMaOez4dB/E06SVMsBQ0W+ Er4zvXJp1gaf0H3ptuwCodZ0ewRFhMrkQHU8DK19vA== X-Google-Smtp-Source: ABdhPJz7z2X87zi2gHmfkAhv+g3fXHvwguoTjKVadVygUMK05U6oCXWxRpoCYKJtJ7EbRn8B3ifu6UmLIDXROcSXykE= X-Received: by 2002:a05:6402:30ae:: with SMTP id df14mr36407363edb.97.1618344998640; Tue, 13 Apr 2021 13:16:38 -0700 (PDT) MIME-Version: 1.0 References: <87lf9nk2ku.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Andy Lutomirski Date: Tue, 13 Apr 2021 13:16:27 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: Len Brown , Willy Tarreau Cc: 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=-3.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Tue, 13 Apr 2021 20:16:42 -0000 On Mon, Apr 12, 2021 at 4:46 PM Len Brown wrote: > > On Mon, Apr 12, 2021 at 11:21 AM Andy Lutomirski wrote: > > > AMX: Multiplying a 4x4 matrix probably looks *great* in a > > microbenchmark. Do it once and you permanently allocate 8kB (is that > > even a constant? can it grow in newer parts?), potentially hurts all > > future context switches, and does who-knows-what to Turbo licenses and > > such. > > Intel expects that AMX will be extremely valuable to key workloads. > It is true that you may never run that kind of workload on the machine > in front of you, > and so you have every right to be doubtful about the value of AMX. I fully believe that AMX will be amazing when used for the right workload. The problem is that a library may have no way to tell whether a workload is the type of computationally intensive workload for which it makes sense. Imagine you have a little function: int matrix_times_vector(int dim, float *out, const float *matrix, const float *vector); A clever library might use AMX for this. If dim == 4 and the caller is planning to call it in a long, tight loop, maybe this even makes sense. If dim == 4 and it's being called once, AMX is probably a losing proposition. With previous technologies, at least the impact was limited to the function itself and maybe once per call to the caller. But now, with AMX, the program that invoked this takes a performance and memory hit *forever* if it uses AMX once. Beyond that, we have the signal handling issue. One solution, going off of what WIlly mentioned, is: bool amx_begin(void *signal_save_buffer); void amx_end(); In the amx_begin() region, if you get a signal, the AMX state is saved in the buffer. Outside the region, if you get a signal and AMX is in use, the kernel will either unceremoniously kill the task or will deliver SIGYOUBLEWIT. [0] I'm really hoping some userspace people can chime in. [0] We really ought to have a SIGSIGNALFAILURE or something for the case where normal signal delivery fails. This is the userspace equivalent of #DF. SIGYOUBLEWIT could be folded in. There would be a flag in the signal frame saying "don't even try to sigreturn".