public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>, Andi Kleen <andi@firstfloor.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Jonathan McDowell <noodles@earth.li>
Subject: Re: [PATCH v9 2/5] x86/cpuid: Add generic table for cpuid dependencies
Date: Thu, 12 Oct 2017 15:01:36 -0700	[thread overview]
Message-ID: <20171012220136.GL5109@tassilo.jf.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1710121710580.1930@nanos>

On Thu, Oct 12, 2017 at 05:13:34PM +0200, Thomas Gleixner wrote:
> On Thu, 12 Oct 2017, Ingo Molnar wrote:
> > 
> > * Andi Kleen <andi@firstfloor.org> wrote:
> > 
> > > --- /dev/null
> > > +++ b/arch/x86/kernel/cpu/cpuid-deps.c
> > > @@ -0,0 +1,109 @@
> > > +/* Declare dependencies between CPUIDs */
> > > +#include <linux/kernel.h>
> > > +#include <linux/init.h>
> > > +#include <linux/module.h>
> > > +#include <asm/cpufeature.h>
> > > +
> > > +struct cpuid_dep {
> > > +	unsigned short feature;
> > > +	unsigned short depends;
> > > +};
> > 
> > Why are these 16-bit fields? 16-bit data types should be avoided as much as 
> > possible, as they generate suboptimal code.
> 
> I was looking at that as well and decided that we preferrably have a
> compressed data structure. The code which walks the table is hardly
> performance critical and the difference in text size is marginal.


Right it was an attempt to save a tiny bit of text space.
On modern x86 CPUs there is no penalty for 16bit except for slightly
larger code.  The table is far bigger than the few additional 16bit prefixes
in the code

   text    data     bss     dec     hex filename
    436       0       0     436     1b4 arch/x86/kernel/cpu/cpuid-deps.o-short
    572       0       0     572     23c arch/x86/kernel/cpu/cpuid-deps.o-int

But can convert to 4 bytes in the next version.

-Andi

  reply	other threads:[~2017-10-12 22:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-07  0:03 Support generic disabling of all XSAVE features Andi Kleen
2017-10-07  0:03 ` [PATCH v9 1/5] x86/xsave: Move xsave initialization to after parsing early parameters Andi Kleen
2017-10-12  7:18   ` Ingo Molnar
2017-10-07  0:03 ` [PATCH v9 2/5] x86/cpuid: Add generic table for cpuid dependencies Andi Kleen
2017-10-08  8:35   ` Thomas Gleixner
2017-10-12  8:07   ` Ingo Molnar
2017-10-12  8:16     ` Ingo Molnar
2017-10-13 17:46       ` Andi Kleen
2017-10-12 15:13     ` Thomas Gleixner
2017-10-12 22:01       ` Andi Kleen [this message]
2017-10-13  5:30       ` Ingo Molnar
2017-10-13 16:36         ` Andi Kleen
2017-10-12 22:12     ` Andi Kleen
2017-10-07  0:03 ` [PATCH v9 3/5] x86/cpuid: Make clearcpuid an early param Andi Kleen
2017-10-12  8:09   ` Ingo Molnar
2017-10-07  0:03 ` [PATCH v9 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling Andi Kleen
2017-10-08  8:34   ` Thomas Gleixner
2017-10-12  8:11   ` Ingo Molnar
2017-10-13 17:48     ` Andi Kleen
2017-10-07  0:03 ` [PATCH v9 5/5] x86/xsave: Remove the explicit clearing of XSAVE dependend features Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171012220136.GL5109@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=noodles@earth.li \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox