1:10 p.m.
Is there a document or page that details all of the changes in how
recent Fedora Core kernels are built? I've noticed several changes, and
I want to verify I understand them all. I apologize as I've seen some
traffic, but I can't seem to find a definite answer (I'm sure I just
passed over it).
Specifically:
1. The "sourcecode" package, which is now ARCH="noarch"
Assumption:
I assume the package name change was because the ARCH has changed.
Additional Q:
Why is the "sourcecode" package not built by default when
"--target=noarch" is passed? I.e.,
%ifarch noarch
%define builddoc 1
%define buildsource 0
^^^
2. There is another variable in EXTRAVERSIONS, defaults to "root"
Assumption:
I assume this is to differentiate between UML (User Mode Linux)
kernels (so the same build system can be used)?
Additional Q:
Is this a stock kernel change? Or Red Hat only?
3. Athlon no longer a build option at all in the SPEC file
Assumption:
Are there support issues with this? Or was it another reasoning?**
Additional Q:
Is there any reason why we can't "patch back in" just the few changes
into the SPEC so one can build Athlon kernels easily with
"--target=athlon"?
[ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on
Athlon. But turning off the generic support, and optimizing for K7
makes a significant difference for me in engineering applications. ]
Also, to add in Athlon support, you don't have to make it part of the
"all_x86" set. In fact, I made Athlon a separate build conditional on
its own in my own spec file (for 2.6.8-1.541) here (along with a few
other changes):
http://www.vaporwarelabs.com/files/temp/kernel-2.6.8-1.541BS.spec
And for those that want to build Athlon optimized kernels, the .config
files are here:
http://www.vaporwarelabs.com/files/temp/kernel-2.6.8-athlon.config
http://www.vaporwarelabs.com/files/temp/kernel-2.6.8-athlon-smp.config
--
Bryan J. Smith b.j.smith(a)ieee.org
------------------------------------------------------------------
"Communities don't have rights. Only individuals in the community
have rights. ... That idea of community rights is firmly rooted
in the 'Communist Manifesto.'" -- Michael Badnarik
1:18 p.m.
On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote:
1. The "sourcecode" package, which is now
ARCH="noarch"
I assume the package name change was because the ARCH has changed.
Yes.
Why is the "sourcecode" package not built by default
when
"--target=noarch" is passed? I.e.,
There is no need to duplicate the files derivable from the src.rpm in
another package. Kernel modules can now be built with just the kernel
package. There is no need to have the kernel-sourcecode package to
build kernel modules.
2. There is another variable in EXTRAVERSIONS, defaults to
"root"
I assume this is to differentiate between UML (User Mode Linux)
kernels (so the same build system can be used)?
Is this a stock kernel change? Or Red Hat only?
I don't know this one.
3. Athlon no longer a build option at all in the SPEC file
Are there support issues with this? Or was it another reasoning?**
The reason is the one you give below:
[ **BTW, I'm fully aware that the i686 kernel runs fairly
optimized on
Athlon.
But turning off the generic support, and optimizing for K7
makes a significant difference for me in engineering applications. ]
How significant? Is this something most users are going to notice in
their use of the system?
4:42 p.m.
Charles R. Anderson wrote:
On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote:
>3. Athlon no longer a build option at all in the SPEC file
> Are there support issues with this? Or was it another reasoning?**
The reason is the one you give below:
>[ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on
>Athlon.
>But turning off the generic support, and optimizing for K7
>makes a significant difference for me in engineering applications. ]
How significant? Is this something most users are going to notice in
their use of the system?
A. I'm tired of Red Hat holding back on optimizations. The architecture
tree/network that RPM consults is kind of screwed up. Not to mention
that it is ridiculous to compile packages for i386 architecture that
will never run on an i386, especially when the developers have dropped
in MMX instrcutions in the assembly anyways, so the i386 designation is
then meaningless. It would be nice if RPM could call compilations for
say pentium-mmx or pentium2 rather than forcing developers to insert
this code manually via assembly, and possibly misleading those running
regular Pentiums or Pentium Pros into thinking that the code will work
on their computers (although I realize that some oter packages might
need to be changed as well in order for this to really work).
B. Red Hat developers were saying before that we need more optimization
for the Pentium 4 because it is obviously not running as well on i686
optimizations as it could. However, I have yet to see a Pentium 4
optimized Fedora Core kernel come out. Perhaps they're busy debating
about whether to call it pentium4 or i786.
C. If it doesn't hurt and it would probably help, I don't see what's the
matter with making an Athlon-optimized kernel. And considering the
complaints that I have seen, it would make even more sense to make a
Pentium 4-optimized kernel available even if the Athlon one was not
available.
Peace,
William
6:04 p.m.
On 11/28/2004 02:42:41 PM, William M. Quarles wrote:
B. Red Hat developers were saying before that we need more
optimization for the Pentium 4 because it is obviously not running as
well on i686 optimizations as it could. However, I have yet to see a
Pentium 4 optimized Fedora Core kernel come out. Perhaps they're
busy debating about whether to call it pentium4 or i786.
Wouldn't glibc be where you would get the most benefits from
optimization anyway? I'm not convinced you would gain a lot from a
kernel.
btw - a generic kernel can be a real lifesaver. Your cpu or mobo fries,
you can put the hard disk in another machine and boot it - kudzu will
(theoretically, and in my experience it worked) take care of everything
for you as far as change in chiset/nics/whatever, but the kernel has to
be able to boot the box before kudzu can run :)
9 p.m.
On Sun, Nov 28, 2004 at 05:42:41PM -0500, William M. Quarles wrote:
A. I'm tired of Red Hat holding back on optimizations. The
architecture
tree/network that RPM consults is kind of screwed up. Not to mention
that it is ridiculous to compile packages for i386 architecture that
will never run on an i386, especially when the developers have dropped
in MMX instrcutions in the assembly anyways, so the i386 designation is
then meaningless.
Those applications should be doing the relevant cpuid checks at runtime
before using them. Fedora supports processors that don't have MMX.
If you have a list of applications that don't do this, file bugs
in bugzilla.
It would be nice if RPM could call compilations for
say pentium-mmx or pentium2 rather than forcing developers to insert
this code manually via assembly
The number of packages using assembler is tiny compared to the
number of applications shipped. And no gcc options are going to
change that for the most part. gcc is getting better all the time,
but hand-written assembler is hard to beat for speed-critical
operations in packages that really need the speed.
B. Red Hat developers were saying before that we need more
optimization
for the Pentium 4 because it is obviously not running as well on i686
optimizations as it could. However, I have yet to see a Pentium 4
optimized Fedora Core kernel come out. Perhaps they're busy debating
about whether to call it pentium4 or i786.
The idea had crossed my mind to ship the 686 kernel as p4 optimised
the last time this discussion came around for benchmarking purposes.
Not around round tuits.
C. If it doesn't hurt and it would probably help, I don't see
what's the
matter with making an Athlon-optimized kernel.
A number of reasons.
- It's one more column in the matrix of supported kernels to worry about.
This may seem insignificant, but it takes quite a while to push
a kernel package through the buildsystem given how many variants
it spits out. On a busy day (like for eg, just before release), it
can take the better part of a day to get packages built.
- The gain just isn't worth it over the 2.4 kernels.
Now that the runtime optimisations get performed in 2.6, theres only
one thing thats missing that would be in an Athlon optimised kernel,
and thats the optimised copy_page/clear_page, which are really only
a win when a lot of data is being copied back/forth between the kernel,
and even then, only under certain usage patterns. I'll be surprised
if this shows up on any real-world application.
- anyone this concerned about that last 1-2% of performance will want
to recompiling their own kernel anyway to disable such things as
highmem support when not needed, or selinux, or 4g4g, or..
And considering the
complaints that I have seen, it would make even more sense to make a
Pentium 4-optimized kernel available even if the Athlon one was not
available.
As above. A seperate kernel is probably overkill.
Compiling the 686 kernel with gcc tunings for p4 (but no instructions)
might make sense however.
Dave
12:54 a.m.
On Sun, 2004-11-28 at 17:42 -0500, William M. Quarles wrote:
Charles R. Anderson wrote:
> On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote:
>
>>3. Athlon no longer a build option at all in the SPEC file
>> Are there support issues with this? Or was it another reasoning?**
>
> The reason is the one you give below:
>
>>[ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on
>>Athlon.
>
>>But turning off the generic support, and optimizing for K7
>>makes a significant difference for me in engineering applications. ]
>
> How significant? Is this something most users are going to notice in
> their use of the system?
A. I'm tired of Red Hat holding back on optimizations. The architecture
tree/network that RPM consults is kind of screwed up. Not to mention
that it is ridiculous to compile packages for i386 architecture that
will never run on an i386, especially when the developers have dropped
in MMX instrcutions in the assembly anyways, so the i386 designation is
then meaningless. It would be nice if RPM could call compilations for
say pentium-mmx or pentium2 rather than forcing developers to insert
this code manually via assembly, and possibly misleading those running
regular Pentiums or Pentium Pros into thinking that the code will work
on their computers (although I realize that some oter packages might
need to be changed as well in order for this to really work).
If you really are running systems that are about 7 - 10 years old
(pentiums) then you should be using software that was optimized for that
hardware when it was new rather than trying to use the latest software
that is being written for performance on Athalon/P4/Athalon64 and
complaining because this new software is not optimized for your old
hardware.
Software gets updated to follow the performance of the hardware and is
coded to work with the current commonly used versions of hardware with a
lot of backwards compatibility, but not optimized for the older hardware
that is no longer being produced.
You are free to roll your own kernels and optimize them as you see fit
for your specific hardware at any time.
B. Red Hat developers were saying before that we need more
optimization
for the Pentium 4 because it is obviously not running as well on i686
optimizations as it could. However, I have yet to see a Pentium 4
optimized Fedora Core kernel come out. Perhaps they're busy debating
about whether to call it pentium4 or i786.
That is plain whining. The processors are named by the manufacturer.
You cannot lay that blame on redhat developers. Intel is calling their
chips P4, or the new one (maybe?) is the itanium (unless they changed it
again). That is a name chosen by Intel, and not by software
developers/packagers.
Optimizations also belong to the kernel development team, and not redhat
developers.
C. If it doesn't hurt and it would probably help, I don't see
what's the
matter with making an Athlon-optimized kernel. And considering the
complaints that I have seen, it would make even more sense to make a
Pentium 4-optimized kernel available even if the Athlon one was not
available.
See earlier discussion on this list about the kernel and the
architecture specifics. I was told (on this list) that it has been
determined that the i686 code contains optimizations that make a
separate architecture version for the athalon obsolete since the 2.6
kernel is out.
The time frame to search on the archives is just about a month prior to
the FC2 release.
.
Peace,
William
1:44 p.m.
New subject: Recent Fedora Core kernels (plus my SPEC file for 2.6.8-1.541 with Athlon support)
Am So, den 26.09.2004 schrieb Bryan J. Smith um 20:10:
Is there a document or page that details all of the changes in how
recent Fedora Core kernels are built? I've noticed several changes,
and
I want to verify I understand them all. I apologize as I've seen
some
traffic, but I can't seem to find a definite answer (I'm sure I just
passed over it).
Additional Q:
Why is the "sourcecode" package not built by default when
"--target=noarch" is passed? I.e.,
%ifarch noarch
%define builddoc 1
%define buildsource 0
Bryan J. Smith b.j.smith(a)ieee.org
You are not speaking about current FC2 kernels. 2.6.8-1.541 is the
current development kernel. The topic about a separate kernel-sourcecode
"missing" has been discussed to extend on the development / test list.
And Arjan recently posted a short instruction on how to rpmbuild the
kernel source rpm from the src.rpm. As this is not topic for the stable
FC list you should look at the other lists mentioned.
Alexander
P.S. Bryan, please do not change the reply-to addresses like you did! If
you post to this list a reply should be stay here and not be directed to
a different list.
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.8-1.521smp
Serendipity 20:42:40 up 5 days, 22:46, load average: 1.65, 1.46, 1.36
2:24 p.m.
On Sun, 2004-09-26 at 20:10, Bryan J. Smith wrote:
1. The "sourcecode" package, which is now
ARCH="noarch"
Assumption:
I assume the package name change was because the ARCH has changed.
correct; this was during a fc2 update
Additional Q:
Why is the "sourcecode" package not built by default when
"--target=noarch" is passed? I.e.,
%ifarch noarch
%define builddoc 1
%define buildsource 0
^^^
yes the plan is to not ship the sourcecode package at all for fc3 but
release note how to get the sourcecode from the src.rpm
2. There is another variable in EXTRAVERSIONS, defaults to
"root"
Assumption:
I assume this is to differentiate between UML (User Mode Linux)
kernels (so the same build system can be used)?
actually it is to differentiate local builds vs buildsystem builds;
mostly that is for my own sanity so that I know my own local builds and
know that they don't match exact CVS tags
Additional Q:
Is this a stock kernel change? Or Red Hat only?
EXTRAVERSION is strictly defined by Red Hat, in upstream it's designed
for free use for packagers ;)
3. Athlon no longer a build option at all in the SPEC file
the gain Athlon gave previously is, in 2.6 kernels, now a runtime option
not a compiletime option, so no need to have different kernels for
athlon anymore.
Additional Q:
Is there any reason why we can't "patch back in" just the few changes
into the SPEC so one can build Athlon kernels easily with
"--target=athlon"?
why bother ?
[ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on
Athlon. But turning off the generic support, and optimizing for K7
makes a significant difference for me in engineering applications. ]
even in 2.6?
4:16 p.m.
Bryan J. Smith wrote:
[ **BTW, I'm fully aware that the i686 kernel runs fairly optimized on
Athlon. But turning off the generic support, and optimizing for K7
makes a significant difference for me in engineering applications. ]
Are you sure that your custom-compiled kernels still have 4G/4G mode
enabled? As choosing any other mode would give significant performance
enhancements in certain applications.
Regardless, it would probably be helpful if you could
* check exactly what it was that helped (make sure that you only
change the one parameter, and identify how much it's removing generic
support, how much it's Athlon optimisation, and how much it's turning
off 4G/4G).
* benchmark it
* if the performance improvements *are* significant, post it to the
fedora-devel list and file a Request For Enhancement in bugzilla:
the Fedora kernel crew can't help if they don't know there's a
problem.
James.
--
E-mail address: james | In the Royal Air Force a landing's OK,
@westexe.demon.co.uk | If the pilot gets out and can still walk away.
| But in the Fleet Air Arm the outlook is grim,
| If your landings are duff and you've not learnt to
| swim.
7085
days inactive
7149
days old
8 comments
9 participants
participants (9)
-
Alexander Dalloz -
Arjan van de Ven -
Bryan Smith -
Chuck Anderson -
Dave Jones -
James Wilkinson -
Jeff Vian -
Michael A. Peters -
William M. Quarles