From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dietmar Maurer <dietmar@proxmox.com>,
Stefan Hanreich <s.hanreich@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-ceph] fix compatibility with CPUs not supporting SSE 4.1 instructions
Date: Tue, 19 Sep 2023 12:06:31 +0200 [thread overview]
Message-ID: <178f7591-ace7-4892-9e0b-7517f7d61e64@proxmox.com> (raw)
In-Reply-To: <1900241791.3879.1695052940454@webmail.proxmox.com>
Am 18/09/2023 um 18:02 schrieb Dietmar Maurer:
>> One of our users ran into issues with running Ceph on older CPU
>> architectures [1]. This is apparently due to a bug in gcc-12 that
>> leads to SSE 4.1 instructions always being executed rather than
>> dynamically dispatching functions using those instructions.
>
> Cant we fix the GCC bug instead?
>
And recompile *all* packages to ensure binary compat?
Note that this would need much more investigation to actually see if
it is indeed a bug, or if gf-complete does something weird with their
lots of C and inline assembly that is actually fine (i.e., one of the
millions of undefined behavior of C where the compiler can do whatever),
as we really only got reports for this specific library, if it'd be a
more general bug it would probably affect many more programs.
So, compiling with O1 is by far the quickest and more targeted solution
for us, and as gf-compat dynamically dispatches vectorized instructions
depending on available support anyway, it has no real performance impact,
at least none we could measure.
FWIW, the Debian openstack team choose the same solution [0] after
coming to no real conclusion on their research into this matter [1].
[0]: https://salsa.debian.org/openstack-team/third-party/gf-complete/-/commit/03e0314af5e814a7ef74dcf4f9416d60c6322e51
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012935
So, while yes, we could spend (potentially a lot of) time on
investigating this, with the current information we have, I'd rather
avoid that for now, especially as I have a gut-feeling that this
bug is just a result of gf-complete oddness and C being C, and
I don't want to mess with that more than really needed.
next prev parent reply other threads:[~2023-09-19 10:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 15:46 Stefan Hanreich
2023-09-18 16:02 ` Dietmar Maurer
2023-09-19 10:06 ` Thomas Lamprecht [this message]
2023-10-31 9:52 ` [pve-devel] applied: " Thomas Lamprecht
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=178f7591-ace7-4892-9e0b-7517f7d61e64@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=dietmar@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.hanreich@proxmox.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal