Mailing List Archive

On Tue, Aug 29, 2023 at 6:22?AM Victor Ivanov <vic.m.ivanov@gmail.com> wrote:
>
> My existing make.conf has:
>
> COMMON_FLAGS="-march=skylake -O2 -pipe"
> CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse
> sse2 sse3 sse4_1 sse4_2 ssse3"
>
> 1) Replace "-march=skylake" with "x86_64[-v1|v2|v3|v4]" or just "generic"
> 4) Update to "-march=znver4"
> 5) Update CPU_FLAGS_X86 with output of "$ cpuid2cpuflags"
>
> Am I missing anything critical that could break step (8) or any
> packages I should include in step (2) in addition to @system to avoid
> likelihood of segfaults?

Well, you won't get segfaults so much as SIGILL, but I'd probably
simplify a bit.

I'm running on zen1 and these are my current flags:
CFLAGS="-O2 -mtune=znver1 --param l1-cache-line-size=64 --param
l1-cache-size=32 -pipe -funit-at-a-time -fstack-protector"

I do have CPU_FLAGS_X86 set, but it seems like most of these are used
by less critical packages, and I'm not sure how much trouble getting
these wrong would be.

As you can see I'm not even setting march. Maybe I could set it a
little more aggressively and not risk any problems, but I'm concerned
about the situation where I might have an unplanned CPU upgrade. My
motherboard could die, and if it does I'd rather be able to just
replace the motherboard+CPU and not have to fuss around with
rebuilding my entire system from a rescue disk. I'm sure march
performs better than mtune but I'd be surprised if the difference is
more than a percent or two for most general purpose loads. If I had
some high performance application that needed every clock cycle then
I'd probably just build that one application with more optimizations.

In general though your plan seems reasonable. Only thing I would
probably consider is at least rebuilding all of @world with the
unrestrictive -march setting. I might let it upgrade over time to the
newer CPU optimizations, but having random stuff breaking until I
rebuild @world seems like unnecessary pain.

You say you're "thinking about upgrading" so it sounds like you aren't
in a hurry and odds are you don't have the new hardware looking at you
and begging you to boot it up. Doing a full @world rebuild is just a
few cents worth of electricity and a day or two.

That's how I'd look at it personally...

--
Rich

On 29/08/2023 13:22, Victor Ivanov wrote:
> Hello,
>
> I will soon be upgrading from a mobile Skylake platform to a desktop
> Ryzen 7000 series and a full re-install is not an option unless all
> else fails. I'm thinking of simply moving the drive and recompile as
> necessary. I don't see why this wouldn't work, but wanted to double
> check with the community just in case.

The only thing I did after upgrading to a different platform (Intel to
AMD) is *first* switching to sys-kernel/gentoo-kernel-bin on the old
system, move my storage devices to the new system, and then switch back
to sys-kernel/gentoo-sources on the new system.

gentoo-kernel-bin is a pre-compiled kernel that serves as a fallback in
case gentoo-sources won't boot. My CFLAGS are:

-O2 -pipe -mtune=native -march=native -ftree-vectorize

and didn't need changing. CPU_FLAGS_X86 did of course did need changing
(with cpuid2cpuflags.)

Usually, critical packages that serve to get you a command-line login
don't end up using amy "weird" CPU instructions (like AVX512 or
whatever), but other packages might. So it's best to rebuild @world once
your new system can boot.

Thank you both for the suggestions.

Generally speaking the process went very smooth. I decided not to
recompile all of @world a-priori and go for gold.

Initially it 'appeared' to have hung after 'Loading ramdisk' but this
ultimately turned out to be a frame buffer issue as the machine was,
in fact, booting.

I had installed 'sys-kernel/gentoo-kernel-bin' as a fallback option,
as Nikos suggested, and tried booting into it to investigate the
issue. Sadly, it wouldn't even go past 'Waiting for systemd-udevd',
although not freezing so not quite/yet a frame buffer issue with this
kernel. I gave up on it immediately and relied on my gut feeling that
my kernel should have, in fact, booted as expected (SSH to the
rescue).

There are still issues with 'amdgpu' and early frame buffer where it
continues to hang after loading the ramdisk, especially over
DisplayPort and having a separate nVidia dGPU, but I might post
separately re this if I can't figure it out. I suspect DRM issues and
module conflicts (I've explored the nvidia and amdgpu Getntoo Wiki
articles).

All in all this was a success and a _huge_ improvement over my
previous setup, pretty chuffed with the platform. My 'favourite'
package, QtWebEngine, now only takes 28 min to compile (with
+jumbo-build). I'm still to take it out for a spin with actual work,
but expect huge gains.


On 29/08/2023 11:58, Rich Freeman wrote:
> Well, you won't get segfaults so much as SIGILL, but I'd probably
> simplify a bit.

My bad, but at least the general point was conveyed :)

> As you can see I'm not even setting march. Maybe I could set it a
> little more aggressively and not risk any problems, but I'm concerned
> about the situation where I might have an unplanned CPU upgrade. My
> motherboard could die, and if it does I'd rather be able to just
> replace the motherboard+CPU and not have to fuss around with
> rebuilding my entire system from a rescue disk.

This seems sensible. I don't think there's going to be that big of an
improvement with exact -march, as you point out, except in HPC loads.
I could probably have set it "znver3" or "znver2" to cover a wider
range of CPUs. Then again, since I opted for AM5 and, more crucially,
DDR5 it's unlikely that I would be going to an earlier generation
unless all key components happen to fail at the same time. So fingers
crossed nothing fails any time soon.

> I do have CPU_FLAGS_X86 set, but it seems like most of these are used
> by less critical packages, and I'm not sure how much trouble getting
> these wrong would be.

CPU_FLAGS_X86 aren't that critical tbh as not all packages would
leverage these flags. And, realistically, I was expecting the new ones
to be a superset of the old ones which ultimately ended up being the
case. Unlikely that this would be an issue. Perhaps only for some
packages and if doing a backwards migration to an earlier generation
hardware.

> You say you're "thinking about upgrading" so it sounds like you aren't
> in a hurry and odds are you don't have the new hardware looking at you
> and begging you to boot it up.

Not at the time of writing, but parcels did start arriving quite speedily :)

Cheers,
- V