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=-4.0 required=3.0 tests=BAYES_00,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 6A5BFC04FF3 for ; Mon, 24 May 2021 18:06:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 34C6B61400 for ; Mon, 24 May 2021 18:06:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233525AbhEXSIT (ORCPT ); Mon, 24 May 2021 14:08:19 -0400 Received: from mail-ed1-f45.google.com ([209.85.208.45]:39885 "EHLO mail-ed1-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233092AbhEXSIR (ORCPT ); Mon, 24 May 2021 14:08:17 -0400 Received: by mail-ed1-f45.google.com with SMTP id h16so32991370edr.6 for ; Mon, 24 May 2021 11:06:49 -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=ZFilWAFKanClEn/uldncIoFEJ9iJ+NoZjOCtXG1E2iA=; b=khYUBQyik0qfd8SSzc5RjbER36UVtAbOYC0eBIFZ1bK8TxYjemBSXWr/keh8In0Y62 6XAbCGXyZR2XA5yg925S50GLL0PIV1JsPR7jjnli8e26k5PXUaMeb+wtpaRJCPvrc2AE RaplycBDDEzhBidxtBUCD0CCtcPiCLMocOSxk1aSSV3oaj2mpr7eXiPEFyNrcdvW9nMM LaSl1Q1LjKXsDK7dMUUtPH17m01m9T1rmZGaqSjgBAl0+rlJVBSWef9fWYo5i0Vg2A3V +iKO2EySrBe3/zh/jxTRpzOkDZmeCSvo+zoXmnr7zLZkP0WUQF8K1L3PKtA5hIsxHabO 0v2Q== X-Gm-Message-State: AOAM531k54SNvyTok+ygOZh7eQZyS88BZkxacaZDKZ/71PCawYycJp7E WY9GW9neJ0/b915HLy19zA9bOynsAj8XuPGLjFNSKviq X-Google-Smtp-Source: ABdhPJyv0yxOmyw0vMRKQrXRXDOII2V4HkRlaqOtHXhorZ8AMdxF2853MsMNTq0sR8Nh66cG5HT1GScQnPEdTaWxnIc= X-Received: by 2002:aa7:c818:: with SMTP id a24mr27351118edt.310.1621879608583; Mon, 24 May 2021 11:06:48 -0700 (PDT) MIME-Version: 1.0 References: <20210523193259.26200-1-chang.seok.bae@intel.com> <20210523193259.26200-25-chang.seok.bae@intel.com> In-Reply-To: From: Len Brown Date: Mon, 24 May 2021 14:06:37 -0400 Message-ID: Subject: Re: [PATCH v5 24/28] x86/fpu/xstate: Use per-task xstate mask for saving xstate in signal frame To: Andy Lutomirski Cc: "Chang S. Bae" , Borislav Petkov , Thomas Gleixner , Ingo Molnar , X86 ML , "Brown, Len" , Dave Hansen , "Liu, Jing2" , "Ravi V. Shankar" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 23, 2021 at 11:15 PM Andy Lutomirski wrote: > > If I'm reading this right, it means that tasks that have ever used AMX > get one format and tasks that haven't get another one. No. The format of the XSTATE on the signal stack is uncompressed XSAVE format for both AMX and non-AMX tasks, both before and after this patch. That is because XSAVE gets the format from XCR0. It gets the fields to write from the run-time parameter. So the change here allows a non-AMX task to skip writing data (zeros) to the AMX region of its XSTATE buffer. The subsequent patch adds the further optimization of (manually) checking for INIT state for an AMX-task and also skip writing data (zeros) in that case. We should have done this optimization for AVX-512, but instead we guaranteed writing zeros, which I think is a waste of both transfer time and cache footprint. Len Brown, Intel Open Source Technology Center