Why does Red Hat and Fedora software not distinguish between AMD and Intel kernels?

[Reindl Harald]

[builduser at buildserver:~]$ cat /usr/lib/rpm/redhat/rpmrc | grep x86_64
optflags: x86_64 %{__global_cflags} -m64 -mtune=generic

[builduser at 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 at 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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/kernel
> _______________________________________________
> kernel mailing list
> kernel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/kernel
> _______________________________________________
> kernel mailing list
> kernel at 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/

http://www.thelounge.net/signature.asc.what.htm