Project

General

Profile

Actions

Bug #41330

closed

hidden corei7 requirement in binary packages

Added by Kefu Chai over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
mimic, nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

quote from Alexandre Oliva's mail

After upgrading some old Phenom servers from Fedora/Freed-ora 29 to
30's, to ceph-14.2.2, I was surprised by very early crashes of both
ceph-mon and ceph-osd. After ruling out disk and memory corruption, I
investigated a bit noticed all of them crashed during pre-main() init
section processing, at an instruction not available on the Phenom X6
processors that support sse4a, but not e.g. sse4.1.

It turns out that much of librte is built with -march=corei7. That's a
little excessive, considering that x86/rte_memcpy.h would be happy
enough with -msse4.1, but not with earlier sse versions that Fedora is
supposed to target.

I understand rte_memcpy.h is meant for better performance, inlining
fixed-size and known-alignment implementations of memcpy into users.
Alas, that requires setting a baseline target processor, and you'll only
get as efficient an implementation as what's built in.

I noticed an attempt for dynamic selection, but GCC rightfully won't
inline across different target flags, so we'd have to give up inlining
to get better dynamic behavior. The good news is that glibc already
offers dynamic selection of memcpy implementations, so hopefully the
impact of this change won't be much worse than that of enabling dynamic
selection, without the complications.

If that's not good enough, compiling ceph with flags that enable SSE4.1,
AVX2 or AVX512, or with a march flag that implicitly enables them,
would restore current performance, but without that, you will (with the
patch below) get a package that runs on a broader range of processors,
that the base distro (through the compiler's baseline flags) chooses to
support. It's not nice when you install a package on a processor that's
supposed to be supported and suddenly you're no longer sure it is ;
)

Perhaps building a shared librte, so that one could build and install
builds targeting different ISA versions, without having to rebuild all
of ceph, would be a reasonable way to address the better tuning of these
performance-critical bits.

src/spdk/dpdk:

diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
index 7b758094d..ce714bf02 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
@ -40,6 +40,16 @ extern "C" {
static __rte_always_inline void *
rte_memcpy(void *dst, const void *src, size_t n);

#ifndef RTE_MACHINE_CPUFLAG_SSE4_1

static __rte_always_inline void
+rte_memcpy(void *dst, const void *src, size_t n)
{
+ return memcpy(dst, src, n);
}

#else /
RTE_MACHINE_CPUFLAG_SSE4_1 */

#ifdef RTE_MACHINE_CPUFLAG_AVX512F

#define ALIGNMENT_MASK 0x3F
@ -869,6 +879,8 @ rte_memcpy(void *dst, const void *src, size_t n)
return rte_memcpy_generic(dst, src, n);
}

#endif /* RTE_MACHINE_CPUFLAG_SSE4_1 */

#ifdef __cplusplus
}
#endif
diff --git a/mk/machine/default/rte.vars.mk b/mk/machine/default/rte.vars.mk
index df08d3b03..6bf695849 100644
--- a/mk/machine/default/rte.vars.mk
+++ b/mk/machine/default/rte.vars.mk
@ -27,4 +27,4 @
  1. CPU_LDFLAGS =
  2. CPU_ASFLAGS =

-MACHINE_CFLAGS = -march=corei7
# MACHINE_CFLAGS += -march=corei7


Related issues 3 (1 open2 closed)

Related to Ceph - Bug #42112: ceph-mon Illegal instruction (core dumped)Need More Info

Actions
Copied to RADOS - Backport #41350: nautilus: hidden corei7 requirement in binary packagesResolvedNathan CutlerActions
Copied to RADOS - Backport #41351: mimic: hidden corei7 requirement in binary packagesResolvedNathan CutlerActions
Actions #1

Updated by Kefu Chai over 4 years ago

  • Status changed from New to Fix Under Review
  • Pull request ID set to 29728
Actions #2

Updated by Nathan Cutler over 4 years ago

  • Status changed from Fix Under Review to Pending Backport
Actions #3

Updated by Nathan Cutler over 4 years ago

  • Copied to Backport #41350: nautilus: hidden corei7 requirement in binary packages added
Actions #4

Updated by Nathan Cutler over 4 years ago

  • Copied to Backport #41351: mimic: hidden corei7 requirement in binary packages added
Actions #5

Updated by Nathan Cutler over 4 years ago

At https://tracker.ceph.com/issues/41350#note-3 (i.e. in the nautilus backport ticket), Harry Coin wrote:

"The 'silent' requirement that ceph run only on -march=corei7 capable servers killed two ubuntu eoan based systems without warning on what should have been an incremental upgrade. On that distro I tried to disable spdk instead (the other approach to this bug I saw on tracker) but it generated too many errors to deal with.

"There's an important lesson here, an opportunity: Why not create a package option that compiles everything with -march=native, describe it as 'compile for best performance available on this host'. That way downstream distributors can bundle 'binaries with safe assumptions' while yet offering a 'best speed available' option for those willing to compile their own but without forcing them to learn all the ceph-compile-install mysteries for each distro?"

Actions #6

Updated by Nathan Cutler over 4 years ago

Hi Harry. I don't know about any distros other than openSUSE and SUSE Linux Enterprise. In those distros, there isn't any good option for having two different "build flavors" of a package.

In general, distros (and Ceph upstream) typically prioritize building for compatibility over building for performance. In this case the -march=corei7 seems to have snuck in via a submodule.

Actions #7

Updated by Kefu Chai over 4 years ago

  • Assignee deleted (Kefu Chai)
Actions #8

Updated by Brad Hubbard over 4 years ago

  • Related to Bug #42112: ceph-mon Illegal instruction (core dumped) added
Actions #9

Updated by Nathan Cutler over 4 years ago

  • Status changed from Pending Backport to Resolved

While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".

Actions

Also available in: Atom PDF