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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 88B6CC2B9F8 for ; Tue, 25 May 2021 04:48:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 67EC9613D5 for ; Tue, 25 May 2021 04:48:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230410AbhEYEtr (ORCPT ); Tue, 25 May 2021 00:49:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:40650 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230385AbhEYEtq (ORCPT ); Tue, 25 May 2021 00:49:46 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3B65C613BF; Tue, 25 May 2021 04:48:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621918097; bh=QUu5tfKQVM3Gw3sTzewlGAGgi5EaPocb4PRcBWNXEaA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=YH3atK/LXf/NOA5WEyNXtN7KtGkdkN1fesS2mF5gh0Z8F/nd6yFarWDrwlY/GxXfT PVmVZoLBEJqDCXtbsyYGJaVBCbsvW8SPPoNgofqevehJolP60+vWkXj8FEuujgyosM ZBapf7DJp+tNDFSxymfp85wNNGreaach9sRRmaj7sNDMdI3HzgEksOdR5XItV67S/f IC89s0V5m5jT9328/E4AdLwIKyahUasU7BXKN1vUKe2foQZX5D9PUyNA2pLx7xx/Lh 6Q3ExSGlSy1xdz+BVzbKY+dopP2esePUQLM0Fhib1UtfuDKkFr4idEQ8UhIrFhSK07 OZsgIOcKoP9HQ== Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id 4120827C0054; Tue, 25 May 2021 00:48:15 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Tue, 25 May 2021 00:48:15 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdektddgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdelheejjeevhfdutdeggefftdejtdffgeevteehvdfgjeeiveei ueefveeuvdetnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1360A51C005F; Tue, 25 May 2021 00:48:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20210523193259.26200-1-chang.seok.bae@intel.com> <20210523193259.26200-25-chang.seok.bae@intel.com> Date: Mon, 24 May 2021 21:47:53 -0700 From: "Andy Lutomirski" To: "Len Brown" Cc: "Bae, Chang Seok" , "Borislav Petkov" , "Thomas Gleixner" , "Ingo Molnar" , "the arch/x86 maintainers" , "Brown, Len" , "Dave Hansen" , "Liu, Jing2" , "Shankar, Ravi V" , "Linux Kernel Mailing List" Subject: =?UTF-8?Q?Re:_[PATCH_v5_24/28]_x86/fpu/xstate:_Use_per-task_xstate_mask_?= =?UTF-8?Q?for_saving_xstate_in_signal_frame?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 24, 2021, at 11:06 AM, Len Brown wrote: > On Sun, May 23, 2021 at 11:15 PM Andy Lutomirski wro= te: > > > > If I'm reading this right, it means that tasks that have ever used A= MX > > get one format and tasks that haven't get another one. >=20 > No. The format of the XSTATE on the signal stack is uncompressed XSAV= E > format for both AMX and non-AMX tasks, both before and after this patc= h. > That is because XSAVE gets the format from XCR0. It gets the fields > to write from the run-time parameter. >=20 > So the change here allows a non-AMX task to skip writing data (zeros) > to the AMX region of its XSTATE buffer. I misread the patch. I still think this patch is useless. >=20 > The subsequent patch adds the further optimization of (manually) check= ing > for INIT state for an AMX-task and also skip writing data (zeros) in t= hat case. >=20 > We should have done this optimization for AVX-512, but instead we > guaranteed writing zeros, which I think is a waste of both transfer ti= me > and cache footprint. If no one depends on it, it=E2=80=99s not ABI.