Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2132573imu; Wed, 12 Dec 2018 10:02:25 -0800 (PST) X-Google-Smtp-Source: AFSGD/VZKfGhob+lwzT2EMKXhr7+YTjyPQQW7BcpqJSFaoZiDVEpbh4BtcunhGTsU0iI0WEo7Jpc X-Received: by 2002:a17:902:b40d:: with SMTP id x13mr21045362plr.237.1544637744990; Wed, 12 Dec 2018 10:02:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544637744; cv=none; d=google.com; s=arc-20160816; b=wjhF8Dr86W+4WETvNJUGIGyfUn812cp4SUpUZzsN1OtG1aCfOPudm+FJBmshEzYpCP 08dXH0nGPUsKz048HKffBW4owxMT4tIb8xsxW7n0Xo8pGD4YTBuMRWhNUDmM/+rySd06 r9GjSUEpDcZjpk+5UADvNeKQUIzKph3MGofDKUHGz9UbZZntWekct5TEfaefyztMhiYg 45WCTbaWQkCc6pcpmJjre0NEaNhBnMG7czOVRV7NKIWyD0+M90Y5P6DBWYL10SQMHSwY zqSR508gVeMdRSxZ9X42yLydpvjB58C9uC72ZA/UiylQROwQoj3MckdGgDONDp0J4S06 BY1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=mqkCcfPvoOcZqaNgWfQlCzaJvdR8pRoalqVSPYRKuD4=; b=DzsONU4UQ8gn6feco4nx8g2mUoeY3H00v/VV3RDuY1iWrTpf3DhIcT+2zfX3WcVU+d IF4tU2IgtzqyWfNbUr6SO2V4Q5xLmOPpcON45CUGJP/OIECMiAzR9NLCSpQQYv5Tb2n0 sguWrn7cdy7KTTCyuJu7gcpKpUX0KBNaFDpRdg4E2Lbp60shZGKRixFcVs/BNUKd9jhW uszRkd9RwencXui9wZD900G58XfOx2mA878XGlK8wteDcWSRisNsiZMDZBnP16u5rIdb uWX8tUNYL50UIIXMcItqG2hd8wTv3mMbtnKHAvbsPDgdWa2bPF/rG3xzxpqMR+u4Z9k7 HNNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v184si14507104pgd.295.2018.12.12.10.02.10; Wed, 12 Dec 2018 10:02:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728129AbeLLSAs (ORCPT + 99 others); Wed, 12 Dec 2018 13:00:48 -0500 Received: from mga04.intel.com ([192.55.52.120]:55573 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727748AbeLLSAr (ORCPT ); Wed, 12 Dec 2018 13:00:47 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 10:00:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,345,1539673200"; d="scan'208";a="109849189" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by orsmga003.jf.intel.com with ESMTP; 12 Dec 2018 10:00:46 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id E4BDA30237E; Wed, 12 Dec 2018 10:00:46 -0800 (PST) Date: Wed, 12 Dec 2018 10:00:46 -0800 From: Andi Kleen To: David Laight Cc: 'Aubrey Li' , "tglx@linutronix.de" , "mingo@redhat.com" , "peterz@infradead.org" , "hpa@zytor.com" , "tim.c.chen@linux.intel.com" , "dave.hansen@intel.com" , "arjan@linux.intel.com" , "linux-kernel@vger.kernel.org" , Aubrey Li Subject: Re: [PATCH v4 1/2] x86/fpu: track AVX-512 usage of tasks Message-ID: <20181212180046.GG25620@tassilo.jf.intel.com> References: <20181211002448.3520-1-aubrey.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Isn't a thread likely to clear the AVX registers at the end of a function > that uses them. > In particular this removes the massive overhead on certain cpus of > switching between two AVX modes. > So it is actually unlikely that XSAVE will need to save them at all? Only if context switches only happened on function boundaries, which is obviously not the case. Yes the detection mechanism is not 100% accurate, but if AVX is used significantly it should eventually detect it. Think of it as a statistical sampling heuristic. > > As I've also said before the registers are caller saved and since > systems calls are normal function calls the application code > would have to save them across a system call. > This allows the kernel to zero the registers on system call entry > again meaning that XSAVE won't normally have to save them. While I agree this would be nice, the Linux system call ABI wasn't defined like this, so it cannot be done at this point. -Andi