Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Kernel for Xeon compiled on Core i7?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
LarryTheNoob
n00b
n00b


Joined: 14 Nov 2016
Posts: 6

PostPosted: Mon Nov 06, 2017 1:54 pm    Post subject: Kernel for Xeon compiled on Core i7? Reply with quote

Several months ago, one of our developers managed to pretty much delete most of the system drive on our development server. We have managed to recover from backups (rdiff-backup to other server, most of the important data are on unaffected software RAID volumes) and by chrooting from a "live cd" on a flash drive + some minor recompilation of stuff that didn't work.

I need to reinstall the system with a shortest possible downtime before the flash drive goes south or we suffer an extended power outage. I do have the original kernel config file, but I don't have any spare servers with Xeon CPUs, similar motherboard, etc...

* Can I compile a new kernel (and whole system) with same ".config" file on a desktop PC with Intel Core i7?
* If so, will it work on the Xeon Server? (simply pluging the drive from the desktop into the server)
* If so, does it affect compilation and setup of other packages like apache, nginx, php, MariaDB, etc...

:oops: This is a noob question stemming from my lack of understanding of kernel compilation and options. I have looked for the answer, but I might not be asking the right questions. Any advice would be appreciated.
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 5954
Location: Saint Amant, Acadiana

PostPosted: Mon Nov 06, 2017 3:33 pm    Post subject: Reply with quote

Unless you have enabled the experimental feature in kernel config to use -marh=native you can compile the kernel in another box and it will work.
_________________
Please learn how to denote units correctly!

Political Correctness is all about replacing imaginary injustice with real injustice.
Back to top
View user's profile Send private message
LarryTheNoob
n00b
n00b


Joined: 14 Nov 2016
Posts: 6

PostPosted: Mon Nov 06, 2017 4:15 pm    Post subject: Reply with quote

Dear Jaglover, thank you !!! :D
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39270
Location: 56N 3W

PostPosted: Mon Nov 06, 2017 4:51 pm    Post subject: Reply with quote

LarryTheNoob,

The whole system is harder.

When you build the kernel for a different CPU, it works because none of that kernel code ever runs on the build host.

When you build other packages for a different system, you might use a chroot. However, when you do that the build host has to be able to execute at least some of the code for the target. Therefore you need to choose CFLAGS etc that will work on both systems.
This usually results in working buf suboptimal code. In your situation thats probably a price you are willing to pay, as it ned only be temporary.

If your Gentoo installs are out of date, there is a whole new world of pain awaiting.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
LarryTheNoob
n00b
n00b


Joined: 14 Nov 2016
Posts: 6

PostPosted: Tue Nov 07, 2017 11:15 am    Post subject: Reply with quote

NeddySeagoon, thank you for the response,
I probably haven't explained correctly, I understand that I need to compile the kernel, chroot into the new system and compile the packages (as the handbook states). It is good news that I can do so on the Intel Core i7 and it will run on the Xeon.
* according to https://wiki.gentoo.org/wiki/Safe_CFLAGS both of the cpu's are in my case the same cpu architecture (I might have pointed that out sooner, sorry), therefore I can actually even use the "-march=native or specifically -march=sandybridge" switch anyway?
* Is there any chance that I could actually boot up the newly compiled system on the Core i7 to test it out? I am not that concerned about suboptimal code (even though I understand that is not the "gentoo way"), I need to test out dozens of badly/not documented custom fixes and modifications made on the original server over the years that are still important to our developers. BTW: yes - it hasn't been updated for years :( - I am confident I simply don't have the skills to be able to save the original system.
* If not, how similar would the hardware have to be for me to be able to boot up the newly compiled system? I suspect I would need same CPU Architecture, as for the motherboard - would same chipset work or do I need an identical motherboard? (I see similar hw is pretty much obsolete and quite cheap nowadays. On the other hand at that point I could probably just buy any similar server that will handle same RAID cards and memories (to save at least some money) and start from a clean slate..
* Is there a different approach I could take to test out the newly prepared system before i put the drive (actually 2 drives in software RAID 1) into the Xeon server? Do I make sense at all? :oops:
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39270
Location: 56N 3W

PostPosted: Tue Nov 07, 2017 5:10 pm    Post subject: Reply with quote

LarryTheNoob,

Take care with CFLAGS. Run
Code:
gcc -### -E - -march=native 2>&1 | sed -r '/cc1/!d;s/(")|(^.* - )|( -mno-[^\ ]+)//g'
an both systems to see what -march=native really means. See stackoverflow for the full details.

You may only set CFLAGS that appear on both systems. Provided both return identical output, you may use -march=native.

Likewise with CPU_FLAGS_X86. Run cpuid2cpuflags on both systems and only set the common flags.
The CPU_FLAGS_X86 can be derived by eye from the flags line in /proc/cpuinfo.

You can boot into the new install if its root filesystem is on a block volume of some sort.
Block volume means a partition or logical volume. At a pinch, it can be a file but that's ugly.
As far as I know, booting into a subdirectory of a block volume is not supported.

Here is what -march=native does for me.
Code:
$ gcc -### -E - -march=native 2>&1 | sed -r '/cc1/!d;s/(")|(^.* - )|( -mno-[^\ ]+)//g'
-march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -msse4a -mcx16 -msahf -mpopcnt -mabm -mlzcnt -mprfchw -mfxsr --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10


There are use cases to write -march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -msse4a -mcx16 -msahf -mpopcnt -mabm -mlzcnt -mprfchw -mfxsr --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 in CFLAGS rather than -march=native but I'll gloss over that for now.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11416

PostPosted: Wed Nov 08, 2017 2:20 am    Post subject: Reply with quote

If you have a strong need to boot into a subdirectory, you could probably fake it with some clever use of an early userspace and chroot before handing control off to the regular init system. I wouldn't mess with that if avoidable, in part because it moves you away from running the exact same environment in both test and production. You want to minimize variance, especially in a case like this where you cannot quickly revert to a previous known good production environment on the first sign of trouble.

Regarding architecture, I recommend you be conservative for -march. Unless the Xeon system is routinely CPU-bound in its regular duties, you probably care more about Gentoo's flexibility in what to install than you do about building the code for optimal performance. Conservative choices here improve your changes that dissimilar x86 hardware can be used freely.

As far as hardware compatibility, it should be safe to experiment. If the kernel is configured to support exactly the hardware of the old Xeon and no other, you might not be able to bring it up as-is on whatever dissimilar hardware you have at hand. Remember though that the binary distributions (Red Hat, Debian, etc.) ship general purpose kernels that run on a variety of hardware. Your kernel can be built that way, if you know what you need (or can find someone to tell you what you need). When you think you're ready, try slotting the test drive into a spare system and bring it up. The worst case is that it panics on boot if your kernel is not able to operate the test system. Second worst is that it comes up, but is missing some functionality required to bring it up all the way and do your planned validation tests. Either way, I wouldn't expect it to damage your test install, so it shouldn't cost you more than the time required to plug/test it.
Back to top
View user's profile Send private message
LarryTheNoob
n00b
n00b


Joined: 14 Nov 2016
Posts: 6

PostPosted: Wed Nov 08, 2017 4:16 pm    Post subject: Reply with quote

Dear NeddySeagoon, Hu,
thank you guys for your kind response and explanation.

The "-native" CFLAGS on the Xeon server are
Code:
-march=sandybridge -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx -msse4.2 -msse4.1 -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=10240 -mtune=sandybridge -fstack-protector-strong

while on the Core i7 desktop I intend to use for compilation and testing
Code:
-march=sandybridge -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -maes -mpclmul -mpopcnt -mavx -msse4.2 -msse4.1 -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=sandybridge -fstack-protector-strong

(almost identical, except for the l2 cache)

The CPU_FLAGS_X86 are identical
Code:
aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3


As Hu suggested, I suspect in this case it will be better for me to stay away from fine tuning and just go with the generic option as staded in the Safe CFLAGS article :
Code:
-march=sandybridge

The server comes from our old hosting infrastructure, it provides more than ample performance for it's current tasks, I am not afraid to waste some (even significant) part of it. Also, If I understand correctly, since we don't have a replacement for this server at hand, if this one died of old age, I can just go out and buy any used server with sandybridge architecture and won't have to reinstall...
_________________
I studied economy. I don't (really) understand anything. I know dogs smarter than me.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39270
Location: 56N 3W

PostPosted: Wed Nov 08, 2017 6:36 pm    Post subject: Reply with quote

LarryTheNoob,

I would go with -march=native, it will be easier to manage later.
If you want to specify --param l2-cache-size=10240 too for targeting the Xeon, its harmless. I doubt that you will notice the difference.

LarryTheNoob wrote:
Also, If I understand correctly, since we don't have a replacement for this server at hand, if this one died of old age, I can just go out and buy any used server with sandybridge architecture and won't have to reinstall...


That's mostly correct. If you customise your kernel to your current Xeon server and your random replacement has different motherboard hardware, you will need a kernel rebuild to match the new hardware. If you use a generic one size fits all kernel, you can probably move the drives over and boot the new server.

You really need that spare Xeon now. You should be using it to maintain your Gentoo that you go on to deploy on the production system.
Its not safe to update a gentoo system in production, in case you break it.
Its not safe to not update it either, at least for security issues.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum