From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by sourceware.org (Postfix) with ESMTPS id 0E88F3857C52 for ; Fri, 16 Apr 2021 21:54:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0E88F3857C52 Received: by mail-ej1-f54.google.com with SMTP id mh2so22619887ejb.8 for ; Fri, 16 Apr 2021 14:54:56 -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=uNYtdO/g+6WIOvgKoAiURTxI1+VyUIZi9jzIsXvYayY=; b=scYZ9LtZ4pJeQ8VUTNrbxUmW8OWprke/y1b9WclciJIBNuulze7dX5MCl41neq3eMr zQ7tKpr8/x8Scl+oXnO5IXTsHHTMB5TmyrZoGdPUDll1DUb3o4SYOkSFrykS2lOThiIr tuj+CdIftt6ZZ+nroimLh91whuWSjfwnE4dgXa6Jc9bZ50YE5lyLWo/+/pu/JyfSbAbn 0173tGprO95tWcN94f5K0mPOMU3fJTerpcXZCY46JnMoRaCGY/gZ1dgk9eJssT+biDN3 vWCzvX13O9vpaWJM2prgImN05mxeXlNIryne9EQE+R1xjiVMwhrOquhaoQWkt88/1Ezq I4AA== X-Gm-Message-State: AOAM532lwikPPhjppCFECblfbKP3xR6aGgE7bG5NqBJOkD5QVHoSIxA0 JHK1wjz/MVWPu5hXiX2aYVvaVrEwZbKarOAlhOw= X-Google-Smtp-Source: ABdhPJzgJhf2hIDGFAQD7G2Z5O1wvhp1n/pe27/t1Yx4f1F57Iue6J1BFx/xuzfQOCf52uleJqaVfnath2zdZczHv/M= X-Received: by 2002:a17:906:ca45:: with SMTP id jx5mr10461248ejb.417.1618610094953; Fri, 16 Apr 2021 14:54:54 -0700 (PDT) MIME-Version: 1.0 References: <87lf9nk2ku.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Len Brown Date: Fri, 16 Apr 2021 17:54:43 -0400 Message-ID: Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features To: Andy Lutomirski Cc: Willy Tarreau , 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_H3, RCVD_IN_MSPIKE_WL, 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 21:54:59 -0000 On Thu, Apr 15, 2021 at 12:24 PM Andy Lutomirski wrote: > On Wed, Apr 14, 2021 at 2:48 PM Len Brown wrote: > > > ... the transition penalty into and out of AMX code The concept of 'transition' exists between AVX and SSE instructions because it is possible to mix both instruction sets and touch different parts of the same registers. The "unused" parts of those registers need to be tracked to assure that data is not lost when mixing. This concept is moot with AMX, which has its own dedicated registers. > What is the actual impact of a trivial function that initializes the > tile config, does one tiny math op, and then does TILERELEASE? 1. Task takes #NM on first touch of TILE registers 2. Kernel allocates 8KB for that task and dis-arms XFD 3. Kernel context switches XFD with task state If the task takes a signal *before* TILERELEASE 4. XSAVE transfers AMX state to signal stack, XRESTOR the reverse. If the task context switches *before* TILERELEASE 5. kernel context switch XSAVES the AMX state to 8KB context switch buffer, XRESTORE the reverse. If the task takes a signal *after* TILERELEASE 4. XSAVE does NOT transfer AMX state (or zeros) to signal stack, 8KB is consumed on signal stack but not touched. XRESTOR, the reverse. If the task context switches *after* TILERELEASE 5. kernel contexts switch ignores INIT=1 AMX state. 8KB buffer is quiescent. As we discussed previously, there is no impact to frequency from either INIT=0 or INIT=1 AMX state. Frequency is impacted by *compute*, and since there isn't any compute this scenario, there is no frequency impact. As we discussed previously, for INIT=1 (which the kernel guarantees, there is also no impact on power. thanks, Len Brown, Intel Open Source Technology Center