From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Migrate install from Intel 6th gen to AMD Zen 4
Date: Tue, 29 Aug 2023 06:58:37 -0400 [thread overview]
Message-ID: <CAGfcS_mxfC+fMFy8aA31ZQXPesJC889X1jNqLfLg-BVYWNxeRQ@mail.gmail.com> (raw)
In-Reply-To: <CAB=_hA5A=xv1rHUpt8mO5whMyyLtnw9BkYfrYbK+Orn_VNUuRg@mail.gmail.com>
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
next prev parent reply other threads:[~2023-08-29 10:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 10:22 [gentoo-user] Migrate install from Intel 6th gen to AMD Zen 4 Victor Ivanov
2023-08-29 10:58 ` Rich Freeman [this message]
2023-09-01 10:30 ` Victor Ivanov
2023-08-29 12:40 ` [gentoo-user] " Nikos Chantziaras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGfcS_mxfC+fMFy8aA31ZQXPesJC889X1jNqLfLg-BVYWNxeRQ@mail.gmail.com \
--to=rich0@gentoo.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox