Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Skylake/Kaby Lake processors: broken hyper-threading

lists.debian.org

Post reply on HN
Print view View original

271–278 of 278 posts

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#271

Post by arde »

lmm wrote: post #269
arde wrote: post #266

Earlier quoted context omitted.

By ancient I mean that it is 1.7 years old and by now Intel has published 4 later releases (20160607, 20160714, 20161104 and 20170511). I think it's a fair and tame adjective considering this is processor microcode we're talking about and that it made me spend a week of my own time hunting it. You say Ubuntu has a bug to track the microcode package as an exception, but that doesn't seem to be having a positive effect…

> Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer? The whole point of an LTS release is that they will keep a stable baseline for all the packages they're distributing and apply a certain amount of integration testing. If you believe upstream knows best (and I'm not saying you're wrong to do so) then why use LTS…

> The whole point of an LTS release is that they will keep a stable baseline

I think you're confusing an objective (LTS) with a tactic (keeping a stable baseline). Certainly the whole point of LTS is not to keep a stable baseline, but to provide long-term support. And that is clearly violated when Ubuntu chooses to not provide support when it is known to be needed (e.g., listed in an Intel Spec update) and a solution is available by a vendor (e.g., Linux-specific microcode update being made available by Intel). The whole point of LTS is to avoid the bleeding edge while fixing known bugs. Microcode updates is not bleeding edge, it's just patches for known bugs.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#272

Post by jakeogh »

wscott wrote: post #235

Has anyone benchmarked one of these machines before and after applying this microcode update? The options in microcode are rather limited and all are likely to have performance impacts. This is likely disabling functionally to avoid this case. I would hope the patch is smart enough to not apply if threading is not enabled, but who knows.

Would a performance hit go unnoticed?

Usually (always?) it's not a ROM update, the encrypted microcode blob is loaded into the CPU by the OS on every boot via CONFIG_MICROCODE.

some linkrot: http://imgur.com/a/z1uLv

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#273

Post by lmm »

arde wrote: post #271
lmm wrote: post #269

Earlier quoted context omitted.

> Why is Ubuntu second guessing Intel in deciding which microcode update to apply and which to skip? How would Ubuntu know that better than the manufacturer? The whole point of an LTS release is that they will keep a stable baseline for all the packages they're distributing and apply a certain amount of integration testing. If you believe upstream knows best (and I'm not saying you're wrong to do so) then why use LTS…

> The whole point of an LTS release is that they will keep a stable baseline I think you're confusing an objective (LTS) with a tactic (keeping a stable baseline). Certainly the whole point of LTS is not to keep a stable baseline, but to provide long-term support. And that is clearly violated when Ubuntu chooses to not provide support when it is known to be needed (e.g., listed in an Intel Spec update) and a solution…

> the whole point of LTS is not to keep a stable baseline, but to provide long-term support.

No, you've got it backwards. If you just wanted long-term support you'd use a rolling release distribution, of which there are any number (yes some rolling release options are "bleeding edge", but there are stable options too). The whole point of LTS releases is that they are stable baselines that are supported in the long term.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#274

Post by rlpb »

arde wrote: post #270
rlpb wrote: post #268

Earlier quoted context omitted.

Why is this Ubuntu's sole responsibility? Can you not get a UEFI firmware update from your vendor? > I think it's a fair and tame adjective considering this is processor microcode we're talking about... Processor microcode updates haven't, to my knowledge, ever automatically been applied by distributions in the past. In light of that, I don't see how it's reasonable to have an expectation otherwise. > You say Ubuntu…

I don't think yours is a serious answer, what I said already refutes your points. Ubuntu has already made me waste a week and I don't want to waste any more, particularly when you can't or won't listen to what I say and look for irrelevant excuses like the availability of UEFI vendor updates. Just FYI Intel provides these updates for very good reasons and RHEL/CentOS/Fedora have been providing processor microcode upd…

> RHEL/CentOS/Fedora have been providing processor microcode updates for ages now and with relatively frequent updates (see the microcode_ctl RPM changelog)

I wasn't aware of this, thanks. Though I searched, and I found that they've been causing their users problems by doing so: https://rhn.redhat.com/errata/RHBA-2017-0028.html

I think this backs up my point: care must be taken.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#275

Post by itchyouch »

peter_retief wrote: post #267

If I run $grep name /proc/cpuinfo | sort -u model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz then $cat /proc/cpuinfo | grep ht Definitely there under flags Should I be concerned?

Your processor isn't affected. It would be i[357]-[67]xxx processors only.

But a new computer may serve you well...

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#276

Post by arde »

lmm wrote: post #273
arde wrote: post #271

Earlier quoted context omitted.

> The whole point of an LTS release is that they will keep a stable baseline I think you're confusing an objective (LTS) with a tactic (keeping a stable baseline). Certainly the whole point of LTS is not to keep a stable baseline, but to provide long-term support. And that is clearly violated when Ubuntu chooses to not provide support when it is known to be needed (e.g., listed in an Intel Spec update) and a solution…

> the whole point of LTS is not to keep a stable baseline, but to provide long-term support. No, you've got it backwards. If you just wanted long-term support you'd use a rolling release distribution, of which there are any number (yes some rolling release options are "bleeding edge", but there are stable options too). The whole point of LTS releases is that they are stable baselines that are supported in the long te…

If LTS' sole point were to keep a stable baseline, then that point would only be for the benefit of some short-sighted developer whose only interest were to keep his to-do list brief. Even a slightly more forward-looking developer would realize his work's point lies somewhere else, particularly when done in a corporate environment such as Canonical's and not as a hobby (but even when done as a hobby for a community project such as Debian). His work should be oriented towards goals somehow related to the costumer priorities, without whom it ceases to matter. Keeping a stable baseline is unrelated to any costumer or user interest.

The costumer or user of LTS wants, well, Support (fixes) for some extended time (Long Term) and avoiding problems (less bugs), perhaps at the cost of getting less new features. The whole point of LTS is self-explanatory.

Keeping a stable baseline is a tactic used to try to provide long-term support by reducing the amount of new bugs at the cost of less new features. But keeping a stable baseline does not attain the key word, the substantive in LTS: Support. Support is provided only by introducing fixes, and that is exactly what has been omitted in the case of the Intel microcode bugs.

Re: Intel Skylake/Kaby Lake processors: broken hyper-threading

#278

Post by breck »

jldugger wrote: post #197
scott_s wrote: post #176

Earlier quoted context omitted.

Can you provide a citation? I'd like to read it.

Ah, found it: "Cosmic Rays Don't Strike Twice" http://www.cs.toronto.edu/~bianca/papers/ASPLOS2012.pdf

Fantastic paper. Thanks for sharing! Just posted it here: https://news.ycombinator.com/item?id=14697744
Post reply on HN