Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Binhosting: CPU instruction set for 'silvermont' vs 'znver1'
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
kgdrenefort
Guru
Guru


Joined: 19 Sep 2023
Posts: 313
Location: Somewhere in the 77

PostPosted: Fri Apr 05, 2024 12:46 pm    Post subject: Binhosting: CPU instruction set for 'silvermont' vs 'znver1' Reply with quote

Hello,

Re-doing a badly made binhost and trying to take care of every details, I have this first question:

The binhost (Mephistopheles) have these values:
Code:
root@Mephistopheles ~ # resolve-march-native
-march=znver1 --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=512


Code:
root@Mephistopheles ~ # cpuid2cpuflags
CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3


For this CPU: 12 × AMD Ryzen 5 2600 Six-Core Processor

While client (lilith) have:

Code:
(chroot) root@livecd / # cpuid2cpuflags
CPU_FLAGS_X86: mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3

Code:
(chroot) root@livecd / # resolve-march-native
-march=silvermont --param=l1-cache-line-size=64 --param=l1-cache-size=24 --param=l2-cache-size=1024


For this CPU: Intel(R) Celeron(R) CPU N2840 @ 2.16GHz

---

I'm pretty sure to have already asked, months ago, this question on #gentoo@libera.chat, but it's lost in the oblivion.

After reading a bit of this page: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

I found that 'silvermont' (client) has not these instructions set from 'znver1':

(from the GCC page:)
Code:
SAHF, FXSR, PREFETCHW


(from difference between direct outputed value between both cpuid2cpuflags command)
Code:
aes, avx, avx2, fl16c, sha, sse4


First, I do not understand why the command do not exactly report as the GCC page. I guess that is normal and I should probably refers to what actual systems are outputing.

---

I read from the wiki's page about setting up a binhost:

a great wiki wrote:
The CFLAGS and CXXFLAGS variables used to build the binary packages must be compatible with all clients.

a great wiki wrote:
USE flags for processor specific instruction set features (like MMX, SSE, etc.) must be carefully selected; all clients must support them.

Binary package guide - General prerequisites

And my guess would be that 'znver1' (the binhost, Mephistopheles) can only use these CPU flags instruction sets to build compatible binary for 'silvermont' (the client, lilith):

Code:
mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3


1/ So every flags from silvermont are into znver1, and I should keep the values as above on binhost. And it won't make any problem because all these flags are already in the sets of znver1. Correct ?

2/ In this case, "USE flags" are referring to the CPUs instructions sets, not to be confuse with GLOBAL and LOCAL (USE) flags sets for the system-wide or a specifical package, both are USE flags but not for the same purpose and has not to be mixed around. The CPU USE Flag has NOT to be sets into USE variables from make.conf, they are sets elsewhere in make.conf and portage (CFLAGS, 00cpu-flags file and such). Correct ?

3/ So the binhost, Mephistopheles, has to be set for CFLAGS values according to the target, 'silvermont' (actually installing from live USB). Otherwise, the source code will be build with potentially no-compliant CPU instructions set, would fail and torture me. Is that correct ?

---

Just in case, the output of lscpu on both:

The binhost (Mephistopheles): https://bpa.st/4R3Q

The client (lilith): https://bpa.st/IQBA

Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.
Back to top
View user's profile Send private message
kgdrenefort
Guru
Guru


Joined: 19 Sep 2023
Posts: 313
Location: Somewhere in the 77

PostPosted: Fri Apr 05, 2024 1:14 pm    Post subject: Reply with quote

This is the answer I got on #gentoo@libera.chat:

tirnanog wrote:
mostly correct. 3 isn't quite correct (it would be more accurate to say that you must not specify any flags that result in binaries containing opcodes that the binhost CPU, itself, is not aware of). as far as CFLAGS is concerned, -march=x86-64-v2 is your simplest option by far.


So, from this reply, the set:
Code:
mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3


is valid from binhost to client. And should not make any troubles.

From this point, I could have all that is needed to keep going, I think.

---

EDIT: After much talking about it:

Code:
# Define a convenient helper function
flags() { gcc -march="$1" -Q --help=target; }

# Show the exact differences between two targets (x86-64-v2 and silvermont in this example)
diff -u0 <(flags x86-64-v2) <(flags silvermont) | less -R


Which output for silvermont:

Code:
--- /dev/fd/63  2024-04-05 15:18:17.090086607 -0000
+++ /dev/fd/62  2024-04-05 15:18:17.090086607 -0000
@@ -13 +13 @@
-  -maccumulate-outgoing-args           [disabled]
+  -maccumulate-outgoing-args           [enabled]
@@ -29 +29 @@
-  -march=                              x86-64-v2
+  -march=                              silvermont
@@ -124 +124 @@
-  -mmovbe                              [disabled]
+  -mmovbe                              [enabled]
@@ -145 +145 @@
-  -mpclmul                             [disabled]
+  -mpclmul                             [enabled]
@@ -155 +155 @@
-  -mprfchw                             [disabled]
+  -mprfchw                             [enabled]
@@ -160 +160 @@
-  -mrdrnd                              [disabled]
+  -mrdrnd                              [enabled]
@@ -204 +204 @@
-  -mtune=                              generic
+  -mtune=                              silvermont


And for znver1:

Code:

--- /dev/fd/63   2024-04-05 15:24:09.350090570 -0000
+++ /dev/fd/62   2024-04-05 15:24:09.350090570 -0000
@@ -12 +12 @@
-  -mabm                             [disabled]
+  -mabm                             [enabled]
@@ -15,2 +15,2 @@
-  -madx                             [disabled]
-  -maes                             [disabled]
+  -madx                             [enabled]
+  -maes                             [enabled]
@@ -29 +29 @@
-  -march=                           x86-64-v2
+  -march=                           znver1
@@ -31,2 +31,2 @@
-  -mavx                             [disabled]
-  -mavx2                            [disabled]
+  -mavx                             [enabled]
+  -mavx2                            [enabled]
@@ -34 +34 @@
-  -mavx256-split-unaligned-store    [disabled]
+  -mavx256-split-unaligned-store    [enabled]
@@ -58,2 +58,2 @@
-  -mbmi                             [disabled]
-  -mbmi2                            [disabled]
+  -mbmi                             [enabled]
+  -mbmi2                            [enabled]
@@ -65 +65 @@
-  -mclflushopt                      [disabled]
+  -mclflushopt                      [enabled]
@@ -67 +67 @@
-  -mclzero                          [disabled]
+  -mclzero                          [enabled]
@@ -78 +78 @@
-  -mf16c                            [disabled]
+  -mf16c                            [enabled]
@@ -83 +83 @@
-  -mfma                             [disabled]
+  -mfma                             [enabled]
@@ -89 +89 @@
-  -mfsgsbase                        [disabled]
+  -mfsgsbase                        [enabled]
@@ -118 +118 @@
-  -mlzcnt                           [disabled]
+  -mlzcnt                           [enabled]
@@ -124 +124 @@
-  -mmovbe                           [disabled]
+  -mmovbe                           [enabled]
@@ -127 +127 @@
-  -mmove-max=                       128
+  -mmove-max=                       256
@@ -132 +132 @@
-  -mmwaitx                          [disabled]
+  -mmwaitx                          [enabled]
@@ -145 +145 @@
-  -mpclmul                          [disabled]
+  -mpclmul                          [enabled]
@@ -151 +151 @@
-  -mprefer-vector-width=            none
+  -mprefer-vector-width=            128
@@ -155 +155 @@
-  -mprfchw                          [disabled]
+  -mprfchw                          [enabled]
@@ -160,2 +160,2 @@
-  -mrdrnd                           [disabled]
-  -mrdseed                          [disabled]
+  -mrdrnd                           [enabled]
+  -mrdseed                          [enabled]
@@ -175 +175 @@
-  -msha                             [disabled]
+  -msha                             [enabled]
@@ -186 +186 @@
-  -msse4a                           [disabled]
+  -msse4a                           [enabled]
@@ -196 +196 @@
-  -mstore-max=                      128
+  -mstore-max=                      256
@@ -204 +204 @@
-  -mtune=                           generic
+  -mtune=                           znver1
@@ -218,4 +218,4 @@
-  -mxsave                           [disabled]
-  -mxsavec                          [disabled]
-  -mxsaveopt                        [disabled]
-  -mxsaves                          [disabled]
+  -mxsave                           [enabled]
+  -mxsavec                          [enabled]
+  -mxsaveopt                        [enabled]
+  -mxsaves                          [enabled]


From these both, we can say that this is the safe way:

Code:
CFLAGS="-march=x86-64-v2 -mmovbe -mpclmul -mprfchw -mdrdnd"


For the binhost.

The client would use -march=native.


Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.
Back to top
View user's profile Send private message
kgdrenefort
Guru
Guru


Joined: 19 Sep 2023
Posts: 313
Location: Somewhere in the 77

PostPosted: Fri Apr 05, 2024 1:47 pm    Post subject: Reply with quote

To add more precision, this is what should looks like my make.conf for the binhost:

Code:

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.
COMMON_FLAGS="-march=x86-64-v2 -O2 -pipe -mmovbe -mpclmul -mprfchw -mrdrnd"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

# NOTE: This stage was built with the bindist Use flag enabled

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C.utf8


And the client should only differ by having:

Code:
COMMON_FLAGS="-march=native -O2 -pipe"


Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 5184
Location: Bavaria

PostPosted: Fri Apr 05, 2024 2:02 pm    Post subject: Reply with quote

Moved from Installing Gentoo to Documentation, Tips & Tricks.

I think our readers will find this document easier here.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Back to top
View user's profile Send private message
kgdrenefort
Guru
Guru


Joined: 19 Sep 2023
Posts: 313
Location: Somewhere in the 77

PostPosted: Fri Apr 05, 2024 3:49 pm    Post subject: Reply with quote

pietinger wrote:
Moved from Installing Gentoo to Documentation, Tips & Tricks.

I think our readers will find this document easier here.


If you think it's better like this :) !

It was not the purpose, at first I hoped an answer from the forum, but it comes from the IRC channel and just edited it for me as for others.
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Fri Apr 05, 2024 4:36 pm    Post subject: Reply with quote

kgdrenefort,

There are two problems to deal with.

The built host can emit code for any amd64 CPU bunt may not be able to execute it. Keep that thought.
There are two places where that matters.

1. In the toolchain doing the building. You don not a want a broken toolchain.
2. In build systems that build code that happens to contain instructions that the build host cannot execute, the the build system executes that code as a part of the build process.

Depending on how much time you want to put into setting up the binhost, there are two solutions.
Find some common CPU flags, or per package CPU flage for the problem packages.
See What Goes Wrong.
_________________
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
kgdrenefort
Guru
Guru


Joined: 19 Sep 2023
Posts: 313
Location: Somewhere in the 77

PostPosted: Sat Apr 06, 2024 9:48 am    Post subject: Reply with quote

Thanks for you reply Neddy.

So far, it seems to works.

I have been able to finish the installation, and made it with most of 95% binary packages from the binhost I made.

I have now rebooted and have to finish the setup. But the system rebooted with a kernel binary I compiled on the binhost, and it boots, as for grub etc.

So I think the guidance of tirnanog was really useful to me and maybe avoided me some troubles.

NeddySeagoon wrote:
There are two problems to deal with.

The built host can emit code for any amd64 CPU bunt may not be able to execute it. Keep that thought.
There are two places where that matters.

1. In the toolchain doing the building. You don not a want a broken toolchain.
2. In build systems that build code that happens to contain instructions that the build host cannot execute, the the build system executes that code as a part of the build process.


It seems that any instructions from silvermont is into the flags set of znver1, so if I understood, that won’t be a problem.

For example I was able to compile lighttpd with the CPU flag sets from silvermont on znver1 and it works flawlessly. Maybe that is not the best example, maybe lighttpd was not a problem but some other tools will have some.

I’ll update the topic about how it worked, if I missed something regarding the binhost-compliance with the client.

Regards,
GASPARD DE RENEFORT Kévin
_________________
Traduction wiki, pour praticiper.
Custom logos/biz card/website.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Sat Apr 06, 2024 10:13 am    Post subject: Reply with quote

kgdrenefort,

Quote:
For example I was able to compile lighttpd with the CPU flag sets from silvermont on znver1 and it works flawlessly.


I would expect anything that builds on the build host for the target to run correctly on the target.
Problems arise when code built for the target is run on the build host,
That can happen either deliberately, with something like gcc, or as a build product, say if the lighttpd builds something for the target in the course of the build, then tries to run it on the build host.
This sort of thing stands out like a sore thumb when cross compiling because trying to run arm code on amd64 fails very quickly.

Its more subtle in the case of a chroot same arch build. The build system is not compelled to use the entire instruction set for the target. When it chooses a subset that the host can execute everything works.


Thank you for for your signature. I missed that wee gem by figueroa :)
_________________
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
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22771

PostPosted: Sat Apr 06, 2024 3:16 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Thank you for for your signature. I missed that wee gem by figueroa :)
That comes from figueroa's first response in What happens if I don't execute emptytree?. It does work nicely even without context, though.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks 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