public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Rusty Trivial Russell <trivial@rustcorp.com.au>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: [TRIVIAL] [resend patch] CONFIG_X86_GENERIC description fixup
Date: Thu, 4 Sep 2003 13:20:29 +0100	[thread overview]
Message-ID: <20030904122029.GA3357@redhat.com> (raw)
In-Reply-To: <20030904033019.794AD2C0B1@lists.samba.org>

On Thu, Sep 04, 2003 at 01:26:41PM +1000, Rusty Trivial Russell wrote:
 
 >   as per thread on lkml a little while ago, a better explanation
 >   of the X86_GENERIC config option follows. The person who questioned
 >   it originally seemed to like this improved version, so that's one point :)

How about explaining _exactly_ what it does? This is still a somewhat
mysterious description. "generic optimisations" what is that ?

 > --- trivial-2.6.0-test4-bk5/arch/i386/Kconfig.orig	2003-09-04 13:02:02.000000000 +1000
 > +++ trivial-2.6.0-test4-bk5/arch/i386/Kconfig	2003-09-04 13:02:02.000000000 +1000
 > @@ -303,9 +303,13 @@
 >  config X86_GENERIC
 >         bool "Generic x86 support" 
 >         help
 > -       	  Including some tuning for non selected x86 CPUs too.
 > -	  when it has moderate overhead. This is intended for generic 
 > -	  distributions kernels.
 > +	  Instead of just including optimizations for the selected
 > +	  x86 variant (e.g. PII, Crusoe or Athlon), include some more
 > +	  generic optimizations as well. This will make the kernel
 > +	  perform better on x86 CPUs other than that selected.
 > +
 > +	  This is really intended for distributors who need more
 > +	  generic optimizations.

All that it seems to do right now is set the cacheline size to the
same as it would if the kernel was compiled for P4, regardless of
what target CPU is selected, so that for eg, an i686 kernel won't
perform any worse on a P4, saving vendors shipping seperate P4 kernels.
it should also note what performance impact (if any) users of this
option will see if they run such a kernel on a box with a smaller
cacheline size.

If this option ever does anything else, that too should get documented here.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

  reply	other threads:[~2003-09-04 12:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-04  3:26 [TRIVIAL] [resend patch] CONFIG_X86_GENERIC description fixup Rusty Trivial Russell
2003-09-04 12:20 ` Dave Jones [this message]
2003-09-05  0:15   ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2003-07-21 11:24 Rusty Trivial Russell
2003-07-07  7:57 Rusty Trivial Russell
2003-06-23  7:19 Rusty Trivial Russell

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=20030904122029.GA3357@redhat.com \
    --to=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=trivial@rustcorp.com.au \
    /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