linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Schlemmer <azarah@gentoo.org>
To: Andi Kleen <ak@suse.de>
Cc: Adrian Bunk <bunk@fs.tum.de>,
	jgarzik@pobox.com, ebiederm@xmission.com, akpm@osdl.org,
	richard.brunner@amd.com, LKML <linux-kernel@vger.kernel.org>,
	torvalds@osdl.org
Subject: Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
Date: Fri, 12 Sep 2003 21:05:06 +0200	[thread overview]
Message-ID: <1063393505.3371.207.camel@workshop.saharacpt.lan> (raw)
In-Reply-To: <20030912202851.3529e7e7.ak@suse.de>

On Fri, 2003-09-12 at 20:28, Andi Kleen wrote:
> On Fri, 12 Sep 2003 20:22:16 +0200
> Adrian Bunk <bunk@fs.tum.de> wrote:
> 
> 
> > 
> > But even CONFIG_X86_GENERIC doesn't do what you expect. A kernel 
> > compiled for Athlon wouldn't run on a Pentium 4 even with 
> > CONFIG_X86_GENERIC.
> 
> It does. Just try it.
> 
> > 
> > Quoting arch/i386/Kconfig in -test5:
> > 
> > <--  snip  -->
> > 
> > config X86_USE_3DNOW
> >         bool
> >         depends on MCYRIXIII || MK7
> >         default y
> 
> That's obsolete and could be removed. All 3dnow! code is dynamically patched depending on the CPUID.
> 

Ok, so how many instructions was added by this ?  Or is it
just in the init code ?  What else just add 'just another
one or two instructions' to common paths because of this?

Which ever way, the point I and some of the others (besides the
additional one from the embedded guys) want to make, is if I
select the CPU to be Pentium4, it means I want a kernel that is
optimised for my P4, without extra crap that I do not need.  Sure,
its an extra instruction here, two there, etc - but when will it
be too much ?  Is this not maybe the fabled 'slight slowdown' that
so many  people complain about from round the 2.5.[67]'s ?

Ok, so maybe my opinion about X86_GENERIC is not as intended, but
then IMHO, it should be 'fixed'.  I could not care less if my kernel
only boot just on my box, never mind on another P4 - I just want
the most optimised on possible.  Sure, some guys want a more generic
kernel - get X86_GENERIC to work for them.  Same for distro's.

I have long wondered if everything in arch/i386/kernel/cpu/ is
really linked in (meaning with no #ifdef as it now looks to be
at a quick peek), or if it was just easier to link them all,
but have non generic stuff (amd/cyrix/whatever specific code)
filtered by ifdef's.

This is just me, but why then don't we then just drop the specific
arch selection, and just have generics instead of pulling a sock
over the user's eyes ?


Thanks,

-- 
Martin Schlemmer



  parent reply	other threads:[~2003-09-12 19:15 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-11  0:56 Update on AMD Athlon/Opteron/Athlon64 Prefetch Errata richard.brunner
2003-09-11  1:27 ` [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata Andi Kleen
2003-09-11  1:44   ` Andrew Morton
2003-09-11  1:47     ` Andi Kleen
2003-09-11 14:15       ` Jeff Garzik
2003-09-11 14:26         ` Andi Kleen
2003-09-11 14:34           ` Jeff Garzik
2003-09-11 14:58             ` Andi Kleen
2003-09-11 15:06               ` Jeff Garzik
2003-09-11 20:08               ` bill davidsen
2003-09-11 19:56             ` bill davidsen
2003-09-11 20:44               ` Alan Cox
2003-09-11 21:29                 ` Mike Fedyk
2003-09-11 21:38                 ` bill davidsen
2003-09-12 17:32             ` Eric W. Biederman
2003-09-12 17:56               ` Andi Kleen
2003-09-12 17:59                 ` Jeff Garzik
2003-09-12 18:22                   ` Adrian Bunk
2003-09-12 18:28                     ` Andi Kleen
2003-09-12 18:39                       ` Jeff Garzik
2003-09-12 18:45                       ` Jeff Garzik
2003-09-12 18:48                       ` Adrian Bunk
2003-09-12 19:07                         ` Andi Kleen
2003-09-12 19:05                       ` Martin Schlemmer [this message]
2003-09-12 19:30                         ` Andi Kleen
2003-09-12 19:58                           ` Martin Schlemmer
2003-09-12 20:00                           ` Adrian Bunk
2003-09-15  0:15                           ` bill davidsen
2003-09-14 23:51                       ` bill davidsen
2003-09-14 23:49                     ` bill davidsen
2003-09-14 23:47                 ` bill davidsen
2003-09-15  1:02                   ` Zwane Mwaikambo
2003-09-15  2:08                     ` Nick Piggin
2003-09-15  3:55                     ` Bill Davidsen
2003-09-15  7:45                       ` Alan Cox
2003-09-15 12:11                         ` Bill Davidsen
2003-09-15 13:48                           ` Alan Cox
2003-09-15 18:50                             ` Bill Davidsen
2003-09-12 18:03               ` Mike Fedyk
2003-09-11 13:54   ` Linus Torvalds
2003-09-11 14:01     ` Andi Kleen
2003-09-11 14:14       ` Dave Jones
2003-09-11 14:29         ` Andi Kleen
2003-09-11 14:14     ` Alan Cox
2003-09-11 14:24       ` Andi Kleen
2003-09-11 14:28         ` Dave Jones
2003-09-11 14:32           ` Andi Kleen
2003-09-11 20:14         ` bill davidsen
2003-09-11 16:58   ` Jamie Lokier
2003-09-11 17:05     ` Andi Kleen
2003-09-11 17:32       ` Jamie Lokier
2003-09-11 17:39         ` Andi Kleen
2003-09-11 17:48           ` Jamie Lokier
2003-09-11 18:18             ` Andi Kleen
2003-09-11 18:59               ` Jamie Lokier
2003-09-11  3:43 Nakajima, Jun
2003-09-11  4:03 ` Valdis.Kletnieks
     [not found] <uqD5.3BI.3@gated-at.bofh.it>
2003-09-11  4:14 ` Andi Kleen
2003-09-11  4:58   ` dada1
2003-09-11  5:11     ` Andi Kleen
2003-09-11  5:58       ` dada1
2003-09-11  4:55 richard.brunner
2003-09-11 16:55 ` Jamie Lokier
2003-09-12 14:14 ` Martin Schlemmer
2003-09-11 17:09 richard.brunner
2003-09-11 17:14 richard.brunner
2003-09-11 17:17 richard.brunner
2003-09-13 16:54 ` Pavel Machek
2003-09-12 21:24 John Bradford
2003-09-15  6:32 John Bradford
2003-09-15  7:40 ` Alan Cox
2003-09-15 12:02   ` Bill Davidsen
2003-09-15 11:48 ` Bill Davidsen
2003-09-15 20:55 ` Adrian Bunk
2003-09-16  0:26   ` Bill Davidsen
2003-09-15  8:31 John Bradford
2003-09-15  8:32 ` Nick Piggin
2003-09-15 20:51   ` Adrian Bunk
2003-09-15  9:39 John Bradford
2003-09-15  9:58 ` Nick Piggin
2003-09-15 10:54 John Bradford
2003-09-15 10:52 ` Nick Piggin
2003-09-15 13:45 ` Alan Cox
2003-09-15 18:44   ` Bill Davidsen
2003-09-15 11:46 John Bradford
2003-09-15 12:38 ` Nick Piggin
2003-09-15 13:46   ` Chris Meadors
2003-09-15 14:00     ` Nick Piggin
2003-09-16 15:06   ` Bill Davidsen
2003-09-16 15:24     ` Nick Piggin
2003-09-15 12:28 Mikael Pettersson
2003-09-15 18:13 ` Bill Davidsen
2003-09-16 11:54 ` Jamie Lokier
2003-09-15 12:43 John Bradford
2003-09-15 18:21 ` Bill Davidsen
2003-09-15 14:21 John Bradford
2003-09-15 16:21 richard.brunner
2003-09-15 19:15 ` Bill Davidsen
2003-09-16 11:46 ` Jamie Lokier
2003-09-16 13:30   ` Dave Jones
2003-09-16 13:52     ` Bill Davidsen
2003-09-16 15:25       ` Timothy Miller
2003-09-16 16:53         ` Bill Davidsen
2003-09-16 17:22         ` Jamie Lokier
2003-09-16 17:23       ` Jamie Lokier
2003-09-18  7:43 ` Pavel Machek
2003-09-18 14:05   ` Dave Jones
2003-09-18 15:56     ` Jamie Lokier
2003-09-18 17:34   ` Bill Davidsen
     [not found] <200309150632.h8F6WnHb000589@81-2-122-30.bradfords.org.uk.suse.lists.linux.kernel>
     [not found] ` <1063611650.2674.1.camel@dhcp23.swansea.linux.org.uk.suse.lists.linux.kernel>
2003-09-15 18:29   ` Andi Kleen
2003-09-15 19:19 John Bradford
2003-09-15 19:34 John Bradford
2003-09-15 19:25 ` Bill Davidsen
2003-09-15 22:28 ` Alan Cox
2003-09-15 19:51 richard.brunner
2003-09-16  0:01 ` David Lang
2003-09-16  0:20 ` Bill Davidsen
2003-09-16 11:50 ` Jamie Lokier
2003-09-16 13:46   ` Bill Davidsen
2003-09-16 17:21     ` Jamie Lokier
2003-09-15 20:03 Nakajima, Jun
2003-09-15 20:20 Nakajima, Jun
2003-09-16  2:23 richard.brunner

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=1063393505.3371.207.camel@workshop.saharacpt.lan \
    --to=azarah@gentoo.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=bunk@fs.tum.de \
    --cc=ebiederm@xmission.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.brunner@amd.com \
    --cc=torvalds@osdl.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;
as well as URLs for NNTP newsgroup(s).