This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intel microcode update and glibc HLE


On 26-09-2014 15:09, Siddhesh Poyarekar wrote:
> Hi,
>
> The microcode_ctl package recently updated itself to include the
> latest intel microcode update that disables HLE.  This is resulting in
> unbootable Haswell systems on Fedora[1] and elsewhere.  The problem
> seems to be that the microcode update is applied a bit late during
> every boot.  Due to this, the kernel has stale CPU capabilities and
> systemd sees HLE enabled before the microcode update is applied.
> Later, HLE is disabled and the next pthread operation in systemd dies
> with a SIGILL.
>
> The ideal solution for this would probably be to apply the microcode
> update as early as possible during boot, but things get complicated
> with suspend-resume or hibernate, so it's not very simple.  In Fedora
> we're now rebuilding glibc with elision disabled again since keeping
> it enabled is useless and is currently harmful.
>
> Siddhesh
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1146967

I am about to ping about my patches to add support of TLE on POWER8, and
with this recent issue with HLE on Intel lead to an idea of creating
a patch to enabled TLE conditionally using an environment variable.  The
idea is to build GLIBC with TLE enabled, add the environment variable
and let architecture work based on its value.

I know this maybe not the best solution in long term if we aim to enable
TLE as default (we will need to either deprecate the env. var or change its
semantics), but my idea is to let developers a way to evaluate either if
TLE is safe and if it indeed gives the workload a performance boost.

Comments?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]