Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
Thanks, James Harrison
On Fri, Feb 07, 2014 at 02:21:47PM +0000, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
Its exactly as you say, Its just not worth the tradeoff. Maintaining multiple kernels for two arches that are compatible outside their specific extensions or architectural minutae isn't really worth the trouble. While theres some performance gain that may be relevant to some people, the general user isn't going to care so much that its worth our effort to maintain, or their effort to do the research as to which cpu is more worthwhile for them.
Add to that the fact that, if there is an area of code that would benefit from some architecturally specific optimization (i.e. an instruction set extension or pipeline behavior), we do have the option of using mechanisms like the alternatives code to dynamically replace generic instructions with architecturally specific and optimized instructions at run time, which lets us further collapse out kernel to a single build. This is also the mechanism that lets us ship UP and SMP derivatives as a single kernel.
I'm not sure why Ubuntu would be building AMD and Intel kernels separately like that. I guess its not a huge deal to do (just takes extra build and test time, since you have an additional kernel to compile and validate), but its one more variable to have to deal with on the support side, and that gets pretty hard to deal with quickly. You would have to ask Canonical why they do it, but my guess would be that they have a paying customer (or customers) that requested it, and they decided it was worth the money to do.
Neil
Thanks, James Harrison _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Hi. Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
Regarding the Ubuntu part of my email, Is there anyone out there who knows?
Thanks, James
On Friday, 7 February 2014, 14:43, Neil Horman nhorman@redhat.com wrote:
On Fri, Feb 07, 2014 at 02:21:47PM +0000, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
Its exactly as you say, Its just not worth the tradeoff. Maintaining multiple kernels for two arches that are compatible outside their specific extensions or architectural minutae isn't really worth the trouble. While theres some performance gain that may be relevant to some people, the general user isn't going to care so much that its worth our effort to maintain, or their effort to do the research as to which cpu is more worthwhile for them.
Add to that the fact that, if there is an area of code that would benefit from some architecturally specific optimization (i.e. an instruction set extension or pipeline behavior), we do have the option of using mechanisms like the alternatives code to dynamically replace generic instructions with architecturally specific and optimized instructions at run time, which lets us further collapse out kernel to a single build. This is also the mechanism that lets us ship UP and SMP derivatives as a single kernel.
I'm not sure why Ubuntu would be building AMD and Intel kernels separately like that. I guess its not a huge deal to do (just takes extra build and test time, since you have an additional kernel to compile and validate), but its one more variable to have to deal with on the support side, and that gets pretty hard to deal with quickly. You would have to ask Canonical why they do it, but my guess would be that they have a paying customer (or customers) that requested it, and they decided it was worth the money to do.
Neil
Thanks, James Harrison _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
_______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
[builduser@buildserver:~]$ cat /usr/lib/rpm/redhat/rpmrc | grep x86_64 optflags: x86_64 %{__global_cflags} -m64 -mtune=generic
[builduser@buildserver:~]$ cat /usr/lib/rpm/redhat/rpmrc | grep i686 optflags: i686 %{__global_cflags} -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables buildarchtranslate: athlon: i686 buildarchtranslate: geode: i686 buildarchtranslate: pentium4: i686 buildarchtranslate: pentium3: i686 buildarchtranslate: i686: i686
Am 07.02.2014 16:01, schrieb James Harrison:
Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
Regarding the Ubuntu part of my email, Is there anyone out there who knows?
On Friday, 7 February 2014, 14:43, Neil Horman nhorman@redhat.com wrote:
On Fri, Feb 07, 2014 at 02:21:47PM +0000, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
Its exactly as you say, Its just not worth the tradeoff. Maintaining multiple kernels for two arches that are compatible outside their specific extensions or architectural minutae isn't really worth the trouble. While theres some performance gain that may be relevant to some people, the general user isn't going to care so much that its worth our effort to maintain, or their effort to do the research as to which cpu is more worthwhile for them.
Add to that the fact that, if there is an area of code that would benefit from some architecturally specific optimization (i.e. an instruction set extension or pipeline behavior), we do have the option of using mechanisms like the alternatives code to dynamically replace generic instructions with architecturally specific and optimized instructions at run time, which lets us further collapse out kernel to a single build. This is also the mechanism that lets us ship UP and SMP derivatives as a single kernel.
I'm not sure why Ubuntu would be building AMD and Intel kernels separately like that. I guess its not a huge deal to do (just takes extra build and test time, since you have an additional kernel to compile and validate), but its one more variable to have to deal with on the support side, and that gets pretty hard to deal with quickly. You would have to ask Canonical why they do it, but my guess would be that they have a paying customer (or customers) that requested it, and they decided it was worth the money to do.
Neil
Thanks, James Harrison _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Fri, Feb 07, 2014 at 04:15:51PM +0100, Reindl Harald wrote:
[builduser@buildserver:~]$ cat /usr/lib/rpm/redhat/rpmrc | grep x86_64 optflags: x86_64 %{__global_cflags} -m64 -mtune=generic
[builduser@buildserver:~]$ cat /usr/lib/rpm/redhat/rpmrc | grep i686 optflags: i686 %{__global_cflags} -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables buildarchtranslate: athlon: i686 buildarchtranslate: geode: i686 buildarchtranslate: pentium4: i686 buildarchtranslate: pentium3: i686 buildarchtranslate: i686: i686
Note that for the kernel, rpmrc optflags are completely and totally irrelevant. They aren't passed along to the actual kernel build, the kernel specifies all its own flags internally. There are override mechanisms, but we don't use them.
The kernel internals are bright enough to be able to read cpu manufacturer, family, stepping, etc., right off the cpu, so assuming the kernel isn't brand new, there are feature tables and whatnot in the kernel to identify exactly what features the cpu has based on mfg/fam/step/etc.
Am 07.02.2014 16:01, schrieb James Harrison:
Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
Regarding the Ubuntu part of my email, Is there anyone out there who knows?
On Friday, 7 February 2014, 14:43, Neil Horman nhorman@redhat.com wrote:
On Fri, Feb 07, 2014 at 02:21:47PM +0000, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
Its exactly as you say, Its just not worth the tradeoff. Maintaining multiple kernels for two arches that are compatible outside their specific extensions or architectural minutae isn't really worth the trouble. While theres some performance gain that may be relevant to some people, the general user isn't going to care so much that its worth our effort to maintain, or their effort to do the research as to which cpu is more worthwhile for them.
Add to that the fact that, if there is an area of code that would benefit from some architecturally specific optimization (i.e. an instruction set extension or pipeline behavior), we do have the option of using mechanisms like the alternatives code to dynamically replace generic instructions with architecturally specific and optimized instructions at run time, which lets us further collapse out kernel to a single build. This is also the mechanism that lets us ship UP and SMP derivatives as a single kernel.
I'm not sure why Ubuntu would be building AMD and Intel kernels separately like that. I guess its not a huge deal to do (just takes extra build and test time, since you have an additional kernel to compile and validate), but its one more variable to have to deal with on the support side, and that gets pretty hard to deal with quickly. You would have to ask Canonical why they do it, but my guess would be that they have a paying customer (or customers) that requested it, and they decided it was worth the money to do.
Neil
Thanks, James Harrison _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
--
Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33 icq: 154546673, http://www.thelounge.net/
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Fri, Feb 7, 2014 at 10:01 AM, James Harrison jamesaharrisonuk@yahoo.co.uk wrote:
Hi. Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
Fedora builds for the i686 32-bit architecture, and the x86_64 architecture for 64-bit. Those are the base 32-bit and 64-bit architectures that both Intel and AMD processors support. The differences are in the microarchitecture, not the ISA.
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
CPU features and flags are detected at runtime by the upstream kernel. We don't carry any patches for that.
Regarding the Ubuntu part of my email, Is there anyone out there who knows?
I have no idea. Are they simply calling their 64-bit kernels "amd64" instead of x86_64? If so, that is purely a naming thing and they are functionally equivalent on both Intel and AMD CPUs.
josh
On 02/07/2014 10:01 AM, James Harrison wrote:
Hi. Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
The virtualization flags are identified during system boot; they are exposed by cpuid calls to the processor. The kernel contains code that identifies the features and there is code in the kernel that enables these features.
See the kernel's arch/x86/include/asm/cpufeature.h for more details.
P.
See the kernel's arch/x86/include/asm/cpufeature.h for more details.
Thanks!
On Friday, 7 February 2014, 15:28, Prarit Bhargava prarit@redhat.com wrote:
On 02/07/2014 10:01 AM, James Harrison wrote:
Hi. Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
The virtualization flags are identified during system boot; they are exposed by cpuid calls to the processor. The kernel contains code that identifies the features and there is code in the kernel that enables these features.
See the kernel's arch/x86/include/asm/cpufeature.h for more details.
P. _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On Fri, Feb 07, 2014 at 03:01:15PM +0000, James Harrison wrote:
Hi. Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
Yes, again, look at arch/x86/Kconfig[.cpu]. There is a generic option for x86_64 arches.
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
What? You have this backwards. the kernel doesn't assert virtualization flags (or other feature flags) on a cpu, the kernel retrieves them from the cpu, and make code path decisions based on that information. Specifically the kernel uses the cpuid instruction to fetch cpu flags so the kernel knows what features it can support.
Neil
Thanks for everyone's comments. I understand now.
Cheers, James Harrison
On Friday, 7 February 2014, 15:32, Neil Horman nhorman@redhat.com wrote:
On Fri, Feb 07, 2014 at 03:01:15PM +0000, James Harrison wrote:
Hi. Thanks for the quick reply.
So what architecture does Red Hat compile its kernels for? Having compiled the Linux Kernel, you must specify target architecture. Is there now a "general cpu" option?
Yes, again, look at arch/x86/Kconfig[.cpu]. There is a generic option for x86_64 arches.
For specific CPU features like virtualisation flags, how do kernels know to report the correct CPU features? Is there a Red Hat patch?
What? You have this backwards. the kernel doesn't assert virtualization flags (or other feature flags) on a cpu, the kernel retrieves them from the cpu, and make code path decisions based on that information. Specifically the kernel uses the cpuid instruction to fetch cpu flags so the kernel knows what features it can support.
Neil
_______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
On 02/07/2014 09:21 AM, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Hmm ... I didn't know that. I'm sure there is some reason for it but I know of no kernel issues that require this to be the case. I suppose there *might* be some performance benefit but I would have thought by now we would have heard from Red Hat Customers who require an AMD kernel.
P.
On Fri, Feb 07, 2014 at 09:56:29AM -0500, Prarit Bhargava wrote:
On 02/07/2014 09:21 AM, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Hmm ... I didn't know that. I'm sure there is some reason for it but I know of no kernel issues that require this to be the case. I suppose there *might* be some performance benefit but I would have thought by now we would have heard from Red Hat Customers who require an AMD kernel.
Haven't looked in some time, but last I knew, they don't ship both an amd and an intel kernel. They ship an "i386" kernel, which works for all x86 cpus, amd and intel alike, and they ship an "amd64" kernel, which works for all x86_64 cpus, amd and intel alike. This is the exact same thing as us shipping i386 and x86_64 packages, just slightly different naming (AMD originated the platform, Debian named their 64-bit packages accordingly).
On 02/07/2014 10:19 AM, Jarod Wilson wrote:
Haven't looked in some time, but last I knew, they don't ship both an amd and an intel kernel. They ship an "i386" kernel, which works for all x86 cpus, amd and intel alike, and they ship an "amd64" kernel, which works for all x86_64 cpus, amd and intel alike. This is the exact same thing as us shipping i386 and x86_64 packages, just slightly different naming (AMD originated the platform, Debian named their 64-bit packages accordingly).
I'm wondering if that's the confusion here. They use the old naming convention (which admittedly is still in use in some parts of a certain company that supports Fedora[1]) of "amd64" to describe their 64-bit kernel ...
P.
[1] I've tried getting us to move to "x86" and "x86 32 bit". I've _tried_. /me weeps.
I'm wondering if that's the confusion here.
YES
They use the old naming convention (which admittedly is still in use in some parts of a certain company that supports Fedora[1]) of "amd64" to describe their 64-bit kernel ...
On Friday, 7 February 2014, 15:26, Prarit Bhargava prarit@redhat.com wrote:
On 02/07/2014 10:19 AM, Jarod Wilson wrote:
Haven't looked in some time, but last I knew, they don't ship both an amd and an intel kernel. They ship an "i386" kernel, which works for all x86 cpus, amd and intel alike, and they ship an "amd64" kernel, which works for all x86_64 cpus, amd and intel alike. This is the exact same thing as us shipping i386 and x86_64 packages, just slightly different naming (AMD originated the platform, Debian named their 64-bit packages accordingly).
I'm wondering if that's the confusion here. They use the old naming convention (which admittedly is still in use in some parts of a certain company that supports Fedora[1]) of "amd64" to describe their 64-bit kernel ...
P.
[1] I've tried getting us to move to "x86" and "x86 32 bit". I've _tried_. /me weeps.
_______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Am 07.02.2014 15:21, schrieb James Harrison:
I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
times are changing
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is
for the relevant things the kernel has ASM code on a modern SandyBridge as example it uses AVX if available
for most code there is no difference which can be easily tested by mtune=corei7-avx and generic while often result in a identical binary and if there is a difference you need to draw the line between theory and real runtime differences compared to maintainance burden
if you have a IvyVdrige CPU which supports "rdrand" instructions they are used and additionally thrown in the random pool. if not the kernel does not care _________________________________________
take a look at "lsmod", these are all intel-specific modules if the CPU supports AES-NI for hw-accelerated crypto, a own kernel optimized for Intel would not do anything different in that context
crct10dif_pclmul 14289 0 crc32_pclmul 13113 0 crc32c_intel 22079 0 ghash_clmulni_intel 13259 0
On Fri, 2014-02-07 at 14:21 +0000, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
There is no need to build separate kernels and Ubuntu doesn't either. The x86_64 architecture was created with the AMD Opteron/Athlon64 CPUs and was originally named AMD64. Intel later adopted it as well and went through a couple of names for it before settling. Most people now call the architecture x86_64 because it is the 64bit x86 instruction set. Ubuntu still calls it amd64. They build i386 kernels for 32bit, and amd64 kernels for 64bit, and you would run the amd64 kernel on an Intel 64bit machine as well.
Justin
Hi. I understand.
Thanks, James Harrison
On Friday, 7 February 2014, 15:16, Justin M. Forbes jforbes@redhat.com wrote:
On Fri, 2014-02-07 at 14:21 +0000, James Harrison wrote:
Hello, I remember the times when Redhat software releases (6.2, 7.3, 8, 9) had a specific kernel for AMD and Intel CPUs.
Now forward on to present day and Red Hat software has one kernel build for AMD and Intel CPUs. When was the decision to switch to an all in one encompassing kernel and is there a performance hit. What allows us to have one kernel build for two different CPUs?
The reason I ask these questions is that Ubuntu is still distinguishing between AMD and Intel CPUs. Why, and what is the difference between what they do and what Red Hat do to their Kernel compiles.
Personally, I think that what Red Hat are doing makes maintaining kernels easier. There is a layer of abstraction that hides what the underlying technology is.
Hope someone can spread some light.
There is no need to build separate kernels and Ubuntu doesn't either. The x86_64 architecture was created with the AMD Opteron/Athlon64 CPUs and was originally named AMD64. Intel later adopted it as well and went through a couple of names for it before settling. Most people now call the architecture x86_64 because it is the 64bit x86 instruction set. Ubuntu still calls it amd64. They build i386 kernels for 32bit, and amd64 kernels for 64bit, and you would run the amd64 kernel on an Intel 64bit machine as well.
Justin
_______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
kernel@lists.fedoraproject.org