From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752039AbbEGTfj (ORCPT <rfc822;w@1wt.eu>);
	Thu, 7 May 2015 15:35:39 -0400
Received: from mail-wg0-f50.google.com ([74.125.82.50]:33460 "EHLO
	mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751576AbbEGTfg (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 7 May 2015 15:35:36 -0400
Date: Thu, 7 May 2015 21:35:31 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo2.kernel.org@gmail.com>, linux-kernel@vger.kernel.org,
        Andy Lutomirski <luto@amacapital.net>, Borislav Petkov <bp@alien8.de>,
        Fenghua Yu <fenghua.yu@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 084/208] x86/fpu: Rename xsave.header::xstate_bv to
 'xfeatures'
Message-ID: <20150507193531.GA23511@gmail.com>
References: <1430848300-27877-6-git-send-email-mingo@kernel.org>
 <554904A6.8040503@linux.intel.com>
 <20150505181613.GA28562@gmail.com>
 <55490B1F.3080409@linux.intel.com>
 <20150506061603.GA13720@gmail.com>
 <554A5D23.2030405@linux.intel.com>
 <20150507122209.GB15656@gmail.com>
 <554B7DAA.3040606@linux.intel.com>
 <20150507153302.GA20993@gmail.com>
 <554B8B99.8070602@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <554B8B99.8070602@linux.intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Dave Hansen <dave.hansen@linux.intel.com> wrote:

> >> It's not a problem today because the instruction mask is always 
> >> -1, so it always has every bit set that *MIGHT* be set in 
> >> XSTATE_BV.
> > 
> > Yes. And why would we ever want to narrow it?
> 
> Because it actually allows us to take advantage of the compaction. 
> Think of the layout of a task using protection keys and MPX.
> 
> MPX = 8*4 + 8*2 = 48 bytes.
> PKEYs = 4 bytes
> 
> They'll be spread out in the standard form *OR* the compacted form 
> with a RFBM=-1.  But, with the compacted form with RFBM=PK|MPX_BITS, 
> they'll fit in a cacheline.

but but ... if this is a normal userspace task then it will use AVX on 
modern Linux distros and then we are up to a 1K FPU context size 
already, 48 bytes won't make a visible dent - especially if compacted 
form has some saving cost. With AVX512 we are at around 2K?

I certainly don't _object_ to using the compacted format, as it makes 
sense and it's clearly getting quite a bit of attention from the 
hardware folks, but we should run some timings and such.

In any case I'm mostly just curious, not worried.

Thanks,

	Ingo