Bug 124008 - Suggestion for imrpovement in kernel source
Suggestion for imrpovement in kernel source
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-22 17:05 EDT by William M. Quarles
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-23 07:06:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Pentium II separation patch (2.55 KB, patch)
2004-05-22 17:07 EDT, William M. Quarles
no flags Details | Diff

  None (edit)
Description William M. Quarles 2004-05-22 17:05:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Description of problem:
The 2.6 kernel includes optimization for the Pentium II processor
separate from the the Pentium Pro.  This patch does the same thing for
the 2.4 kernel (it also corrects the gcc -march flag for the Pentium
w/MMX processor, although I doubt that it would make any difference in
the resulting kernel).

Version-Release number of selected component (if applicable):
kernel-source-2.4.22-1.2188.nptl

How reproducible:
Always

Steps to Reproduce:
1. This patch is to be applied inside the kernel source directory
(patch -p1 <pentium2.patch)
2.
3.
    

Additional info:
Comment 1 William M. Quarles 2004-05-22 17:07:36 EDT
Created attachment 100462 [details]
Pentium II separation patch

The 2.6 kernel includes optimization for the Pentium II processor
separate from the the Pentium Pro.  This patch does the same thing for
the 2.4 kernel (it also corrects the gcc -march flag for the Pentium
w/MMX processor, although I doubt that it would make any difference in
the resulting kernel).	It is to be applied inside the kernel source directory
(patch -p1 <pentium2.patch).
Comment 2 Arjan van de Ven 2004-05-22 17:11:08 EDT
As far as I know the flag doesn't actually do anything differently in
nowadays gcc though. (Not surprising since a pII is basically the
exact same core as the Pentium PRO, with the exception that the pII
has MMX added to it)

There obviously is an open matter about which one of the tuning flags
is best for a generic distribution; we're leaning towards optimising
for a pentium 4. The pentium 4 has some instruction sequences it
really doesn't want, and optimising for p4 will avoid those. Yet code
optimized that way will run fast on pII/PIII as well...
Comment 3 William M. Quarles 2004-05-22 21:28:25 EDT
There is one instruction/feature that is non-MMX that is different
between the Pentium II and the Pentium Pro.  What it is, I cannot
recall, I'll have to look through my mail archives.  I figure that the
kernel team wouldn't have bothered separating the two processors

In regards future release tuning flags... I'm going to go on a
tangent, since you did, too.  It would be nice if RPM was finally
updated to support the other P6 and post-P6 processors, as well as
i586-MMX.  I know that back in 1999 the gcc team was working to
include MMX and SIMD instructions.  I assume that they are done by
now.  Something that I would suggest for future releases of Fedora
Core is that programs that could obviously benefit from the newer
multimedia enhancements (let's say Xine, FLAC, XMMS, and Vorbis for
example) have RPMs built for them that make use of the new instruction
sets.  For example:
xmms-1.3.x-1.i386.rpm
xmms-1.3.x-1.pentium2.rpm

would be a good choice, because that gives people their MMX
instructions, and most people using MMX probably have a Pentium 2 or
later.  Or, if you decide to get really generous:
xmms-1.3.x-1.i386.rpm
xmms-1.3.x-1.pentium-mmx.rpm
xmms-1.3.x-1.pentium2.rpm
xmms-1.3.x-1.pentium3.rpm
xmms-1.3.x-1.pentium4.rpm
xmms-1.3.x-1.athlon.rpm

I know that this looks like a lot of extra packages to have to include
on an installation disc, but there are only a few programs in Fedora
Core that would need this, and I think that it might be worth it. 
Even just including an i386 and a pentium2-optimized version of each
multimedia rpm would make a big difference for people.  This would
also give a good punch-in-the-nose to people who say that Linux is not
good for multimedia stuff.  I know that many of the projects are
behind on including instructions that are more up-to-date, but maybe
you can give them a kick in the right direction.
Comment 4 William M. Quarles 2004-05-22 21:44:08 EDT
CORRECTION:

would be a good choice, because that gives people their MMX
instructions, and most people using **XMMS** probably have a Pentium 2
or later.
Comment 5 Dave Jones 2004-05-23 07:06:29 EDT
media players and the like usually detect the cpu and runtime and
adapt accordingly. Compiling it for a specific CPU probably wouldn't
buy you much given they typically have hand-written assembly for each
CPU for the important time-critical functions.

Additionally, I'd be _very_ surprised if you could find a
benchmarkable difference between a generic 686 kernel, and a
pentium-II targetted kernel.  The overhead of having to distribute
extra kernel images (given that we've gone through a lot of effort to
actually ship _less_ images in recent times) makes it very doubtful
that fedora core will ship a pentium ii kernel.

again, for a lot of speed critical stuff, the kernel will adapt
accordingly. If a CPU is capable of using SSE, it will use it for
example.  The RAID5 routines are a good example of this, it benchmarks
several routines during boot up and chooses the fastest.
Comment 6 William M. Quarles 2004-05-23 12:20:56 EDT
I wasn't suggesting that you distribute a Pentium II optimized kernel.
 Far from it.  I was only talking about alternate versions of media
players on the like.

As for the kernel, I was just suggesting that you add the patch for
those interested in building one from the kernel-source package.

I'm surprised that this report has gotten so much attention,
especially on a weekend, for a mere enhancement priority, when several
other higher priority bugs that I have reported or have contributed to
haven't received any response at all.  One of them is approaching its
first birthday.

Note You need to log in before you can comment on or make changes to this bug.