[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 <[email protected]> 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
>> [email protected]
>> https://admin.fedoraproject.org/mailman/listinfo/kernel
> _______________________________________________
> kernel mailing list
> [email protected]
> https://admin.fedoraproject.org/mailman/listinfo/kernel
> _______________________________________________
> kernel mailing list
> [email protected]
> 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
_______________________________________________
kernel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/kernel
