From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 1/2] x86: eliminate TS_XSAVE Date: Mon, 03 May 2010 14:45:43 -0700 Message-ID: <4BDF4407.8000503@zytor.com> References: <1272812038-32484-1-git-send-email-avi@redhat.com> <1272812038-32484-2-git-send-email-avi@redhat.com> <4BDDBA18.3080909@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Gerst , Dexuan Cui , Sheng Yang , Ingo Molnar , linux-kernel@vger.kernel.org, kvm@vger.kernel.org To: Avi Kivity , Suresh Siddha Return-path: In-Reply-To: <4BDDBA18.3080909@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/02/2010 10:44 AM, Avi Kivity wrote: > On 05/02/2010 08:38 PM, Brian Gerst wrote: >> On Sun, May 2, 2010 at 10:53 AM, Avi Kivity wrote: >> >>> The fpu code currently uses current->thread_info->status& TS_XSAVE as >>> a way to distinguish between XSAVE capable processors and older processors. >>> The decision is not really task specific; instead we use the task status to >>> avoid a global memory reference - the value should be the same across all >>> threads. >>> >>> Eliminate this tie-in into the task structure by using an alternative >>> instruction keyed off the XSAVE cpu feature; this results in shorter and >>> faster code, without introducing a global memory reference. >>> >> I think you should either just use cpu_has_xsave, or extend this use >> of alternatives to all cpu features. It doesn't make sense to only do >> it for xsave. >> > > I was trying to avoid a performance regression relative to the current > code, as it appears that some care was taken to avoid the memory reference. > > I agree that it's probably negligible compared to the save/restore > code. If the x86 maintainers agree as well, I'll replace it with > cpu_has_xsave. > I asked Suresh to comment on this, since he wrote the original code. He did confirm that the intent was to avoid a global memory reference. -hpa