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
On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote:
- 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.
- 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.
- 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?
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@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.
On Sun, 2004-09-26 at 20:10, Bryan J. Smith wrote:
- 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
- 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 ;)
- 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?
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.
Charles R. Anderson wrote:
On Sun, Sep 26, 2004 at 02:10:16PM -0400, Bryan J. Smith wrote:
- 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
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 :)
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
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:
- 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
-
Alexander Dalloz -
Arjan van de Ven -
Bryan Smith -
Chuck Anderson -
Dave Jones -
James Wilkinson -
Jeff Vian -
Michael A. Peters -
William M. Quarles