Two Linux Kernels Revert Performance-Killing Spectre Patches (phoronix.com)

Friday Greg Kroah-Hartman released stable point releases of Linux kernel 4.19.4, as well as 4.14.83 and 4.9.139. While they were basic maintenance updates, the 4.19.4 and 4.14.83 releases are significant because they also reverted the performance-killing Spectre patches (involving "Single Thread Indirect Branch Predictors", or STIBP) that had been back-ported from Linux 4.20, according to Phoronix:

There is improved STIBP code on the way for Linux 4.20 that by default just applies STIBP to SECCOMP threads and processes requesting it via prctl() but otherwise is off by default (that behavior can also be changed via kernel parameters). Once that code is ready to go for Linux 4.20, we may see it then back-ported to these stable trees.

Aside from reverting STIBP, these point releases just have various fixes in them as noted for 4.19.4, 4.14.83, and 4.9.139.
Last Sunday Linus Torvalds complained that the performance impact of the STIPB code "was clearly way more expensive than people were told," according to ZDNet: "When performance goes down by 50 percent on some loads, people need to start asking themselves whether it was worth it. It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway," wrote Torvalds. "So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"

Comments

I wonder when

[Anonymous Coward]

Intel will release CPU that is not vulnerable to spectre, meltdown and portsmash variants.

Re:I wonder when

[Anonymous Coward]

They did, it was the 486.

Consider

[3seas]

sometimes I feel the responsiveness of my windows system running on an i7 is slower than a commodore 64. It should make people wonder with all the advances in chip manufacturing, speed and..... Oh wait Moores law doesn't apply to user experience.

Re:Consider

[110010001000]

Moore's Law has been dead for many years now. We can only expect single digit improvements in CPU performance from now on. Of course, someone will reply with "what about quantum computers?" but those people don't even understand what quantum computers are.

Re:Consider

[Anonymous Coward]

The Apple II from the 1983 had the lowest input latency of any computer. Modern computers have about double the input latency.

Re:Consider

[Anonymous Coward]

The problem has nothing to do with Moore's law as such, and everything to do with bad management combined with lazy and incompetent programmers. Not that all programmers are lazy and incompetent, but bad management has those covered.

Moore's law is more tangential to the problem; in the old days hardware was so incredibly limited and expensive that you had to be good to get something worthwhile out of it. Also, writing software wasn't an industry in the same way back then. Moore's law changed that, since it allowed humongous amount of crappy code to be written and shipped cheaply by incompetent and arrogant people (-RAM is cheap! -OF COURSE it is, it's not YOU who're paying for it!). So you could argue that it did indeed manifest itself, only not in faster software but rather the opposite.

Now that Moore's law is dead, we'll see the pendulum swing back the other way; if you want to get a job in the future, you'll have to be good again, or your job will ship to India or China. Chances are that it will eventually anyway, but for the near future, the pressure is going to be how to squeeze out as much performance as possible from what we have. This will include being able to actually write effective code with an increasing stress on horizontal scaling. A good example is to look at games. Just a few of years ago the conventional wisdom was that even a dual core was dubious, compared to having a cpu with a really high clock speed. Today, a quad is questionable from a future proofing standpoint.

Re:Consider

[Anonymous Coward]

Moore's Law isn't dead. It just no longer applies in the realm of personal computing. And why should it? We're fluffing more and more of the workload from the desktop to the cloud server. Think what you will of that trend but it's going to create a bigger gap between what needs to exist on your desk and the kind of computing you'll need in the data center.

Re:Consider

[Anonymous Coward]

Moores' law isn't CPU speed, it's the transistor density.

Re:Consider

[110010001000]

Moore's Law is dead and applies to computers based on transistors. It says nothing about "the cloud".

Re:Consider

[110010001000]

Thanks for the tip. Some pedant always points this out. No one cares. The end result is that CPUs have hit a dead end.

Re:Consider

[aliquis]

Reminds me of these clips:
https://www.youtube.com/watch?...

I've seen others too with say booting the machine, launch word processor, type something, save or print and then turning it off again where the much older machine did it quicker.
https://www.youtube.com/watch?...

Re:Consider

[ArchieBunker]

Oh Christ you again. Moore's law is about transistor count, not speed.

Re:Consider

[110010001000]

Thanks for the tip. I didn't know that. You forgot to mention "what about quantum computers" and "but video card processors".

Re:Consider

[drinkypoo]

sometimes I feel the responsiveness of my windows system running on an i7 is slower than a commodore 64.

For some operations, it is, because the C64 was doing nothing in the background and it could respond immediately. On the other hand, most of your peripherals have more processing power in them than had the C64, and your computer is capable of feats that could not reasonably be achieved with a million C64s wired together. User experience, indeed.

Re: Consider

[Anonymous Coward]

Which is bad for the people who are not in control of those data centers.

Re:Consider

[Anonymous Coward]

geoWrite on a C128 starts faster than Word 2016 on an i7 with a 1TB hard drive.

Re:Consider

[Anonymous Coward]

That's probably about error messages bursting to the log about failed operations, missing rights or components left behind in the Microsoft Fast and Furious update process, to throw another anecdotal musing about the 1809 Windows 10 update.

System response bounded by disk, makes an i7 wonder about its wits;
  Oh why do you spindle those platters, Microsoft, when the consistency of operations is what matters?
The industry wonders about the laws of the Moore, but it is Microsoft that has some rot in its core.

Re:Consider

[Anonymous Coward]

> sometimes I feel the responsiveness of my windows system running on an i7 is slower than a commodore 64.

You know, we cannot blame Intel for everything. Windows alone is lame enough for that.

Re:Consider

[gweihir]

Indeed. And eventually even those single digit improvements will go away. Maybe we can start writing better software now?

Re:Consider

[kobaz]

SSD?

Re:Consider

[Anonymous Coward]

Your brains did, not CPU. no matter you care or not Moores' law isn't about CPU speed, you ignorant idiot

Re:Consider

[Anonymous Coward]

And it's still dead. They have been missing targets for the last decade.

Re:Consider

[110010001000]

I never said it was CPU "speed". It is transistor density which directly maps to performance. And Moore's Law is dead.

Re:Consider

[ceoyoyo]

Moore's law is about transistor *cost*.

Re:Consider

[Anonymous Coward]

Of course we can. It won't matter because people will demand backwards compatibility for their proprietary software.

Re:Consider

[PhunkySchtuff]

If you thought that your i7 is less responsive than a C64... Then you might actually be correct.
Have a look at this guy's research on latency and input lag. Granted, some of the machines he has tested on are fairly dated by now, but the general concept remains that a newer machine, while being essentially infinitely faster than a C64 or an Apple 2e, they all generally take longer to put a character on the screen once you've hit a key on the keyboard. Granted, they're also doing a lot more to put that character there, but the fact remains that overall latency has increased as computers have got faster.

https://danluu.com/input-lag/
https://danluu.com/keyboard-la...

Re:Consider

[HiThere]

The only real way forwards appears to be parallel processing. Unfortunately, many workloads have limiting serial components, and others appear to, because designing good parallel algorithms is really difficult. And, FWIW, there's suggestive evidence that correct, rather than usually correct, algorithms are going to be really hard to do. I don't think it's been proven impossible for most useful cases, but I wouldn't bet money.

It may well be that neural net type applications are the optimal approach.

Re:Consider

[Anonymous Coward]

Thanks for the tip. Some pedant always points this out.

Because some retard like you always brings it up about cpu speed. No do the world a favor and kill yourself.

Re:Consider

[gweihir]

Since parallel architectures have been studied for a long, long time (anybody remember Transputers?), we do know that most things do not really benefit from more cores. The thing were they do best is server loads with lot of independent tasks being run. But most standard stuff does not benefit a lot or not at all. In addition, most coders cannot do multi-threaded software, as that is a lot harder than it looks. Deadlocks, races, etc. are not fun and testing loses effectiveness fast.

Re:Consider

[Anonymous Coward]

I never said it was CPU "speed".

Yes you did.

Moore's Law has been dead for many years now. We can only expect single digit improvements in CPU performance from now on.

You're also so short-sighted that you fail to see the many ways in which CPU performance can improve. Shifting over to using purpose made components in the CPU is one obvious way that even a tech novice such as yourself should have seen.

Re:Consider

[Anonymous Coward]

Nope. i7 on the very chart you linked has 50ms and Commode Pet has 60ms. Commode 64 isn't even listed. The worst ones are mostly Apple computers.

Re: Consider

[peppepz]

Dear companion in old age, are you sure you remember the responsiveness of your C64, or lack thereof? Let's not talk in hyperboles to the point that words no longer have a meaning.

Re:Consider

[Ungrounded Lightning]

Single-threading is falling off the Moore's Law style scaling. Lots of programs are sequential even if they could have been parallelized, so the lazy-man approach of just buying a new machine in one-point-five-ish years to get the same program to run twice as fast is no longer

But the real Moore's law - transistors per chip with adequate yield for market penetration - is still going strong. Parallelizable computations continue to benefit in proportion.

Human minds are built of 'WAY slow logic elements but achieve prodigious computational feats by massive parallelism. They serve as a proof-of-concept that practical and useful massively-parallel computations are possible.

Re:Consider

[Anonymous Coward]

On the C128?

Re:Consider

[tlhIngan]

Moore's Law has been dead for many years now. We can only expect single digit improvements in CPU performance from now on. Of course, someone will reply with "what about quantum computers?" but those people don't even understand what quantum computers are.

Moore's Law doesn't say anything about performance. It only applies to transistor density. And transistor density has nothing to do with performance - other than being able to cram more cache into a processor. (The vast majority of transistors in a processor are for memory - the transistors doing the actual calculation are far far fewer than you'd think - random logic transistors are far less dense than memory).

As a result, Moore's Law applies more towards memory (RAM, flash, etc) than logic devices. Logic devices are dominated by how dense you can make the wiring. In fact, there are so few transistors, chip makers traditionally sprinkle those areas with footprints for inactive transistors so they have spares they can wire in during minor stepping revisions.

Re:Consider

[sad_]

why not?

Re:Consider

[HiThere]

No. What we know is that using our current algorithms most things don't really benefit for more parallelism. You can't reasonably use the same algorithm on a process for parallel computation as for serial computation. And designing good parallel algorithms is *HARD*. So we've only got a few.

There's also suggestive evidence that there's often not a good algorithm, but only quite good heuristics, and often you can test the answer faster than you can solve it. When you can't, you gamble that multiple heuristics returning the same result yields something "close enough" to the correct answer.

It also depends on how complex the problem is that you're trying to deal with. Simple problems are more likely to not benefit from complex approaches.

Re:Consider

[gweihir]

We have been designing parallel algorithms for 40 years now, because it was always clear that multi-core will eventually be the only way to scale and because we have had massive parallel systems for about that long. What we have is hence the results from intensive studies. It is not much. It is likely close to what we will have long-term.

Hence our "current" algorithms very much include parallel ones. If you think that we do not have more good parallel algorithms is a result from too little research, you are very much mistaken.

Re:Consider

[Bengie]

I've seen a lot of designs that were made single threaded because contention was too high to be useful concurrently, but it was a self-fulfilling prophecy because the engineers never realized that perfect is the enemy of good. There are many cases where certain data types can be lossy and not hurt anything, and in these cases, contention could be virtually eliminated if the engineers could think outside the box.

I see engineers designing locks with the idea of preserving ordering, even when ordering does not matter, or making sure that an ephemeral aggregate value is 100% correct when 99% correct is good enough. People like to make a problem fit the way they understand the problem instead of changing their understanding to fit the problem.

After they add all of these meaningless locks around the system, the complain that the problem can't be parallelized effectively.

Omg, did the packet arrive before the key-press or the other way?! Who the fk cares?! The problem already has fundamental race conditions, adding or removing one more class of race conditions will not matter. Key presses by the user has no synchronization requirements with data coming in from the network. Why create such a dependency? This is a simplistic example of much more complex assumptions of ordering that most people feel compelled to enforce because it simplifies their mental model.

Personally, I like to take the approach of of distributed systems. For some reason, people can handle accepting no guarantee of ordering when you have distinctly separate computers asynchronously processing event streams than different threads doing the same thing in a CPU. They can't seem to grasp the abstractness of an API, and treat web service API(endpoint) calls as something completely magically different than a library API(method) call.

Re:Consider

[Bengie]

I personally think the biggest block to parallelism is everyone used to using pre-made algorithms or libraries and attempting to shoe-horn their problem domain into a limited collection of general purpose parallel algorithms. I find that fit for purpose parallel algorithms and data structures are quite abundant. I've seen rolling my own for a long time. I started parallel programming around the age of 11. I found it quite intuitive. I see race conditions as a form of edge case. All you need to do is design code that has no edge cases. If you're defined and handled all of your edge cases, you cannot have any race conditions.

Whiskey Lake

[JBMcB]

Supposedly Whiskey Lake has hardware mitigations for some variants. I think Cannon Lake is supposed to have mitigations for everything, but the 10nm process is having problems.

Re:Whiskey Lake

[Anonymous Coward]

But it seems like new attacks are coming out every other week, how likely is it that the new design will have mitigations for all of these new attacks?

Re:Whiskey Lake

[aliquis]

Cannon lake definitely doesn't have mitigations for everything.

Intel has claimed that software and hardware mitigations together would defend against the much more resent found flaws too I don't know whatever that's correct or not.

Variants - never

[raymorris]

Variations on the idea will ALWAYS be present in any high performance SMT processor. CPUs are just so complicated and there are so many interactions that as long as there are simultaneous threads, one thread will be able to create resource contention with another.

A solution would be to have a very simple (slow) processor, probably an ARM chip, which handles cryptographic tasks. Complexity is very much the enemy of security, especially regarding the types of side channel attacks you mentioned.

Re:Variants - never

[Anonymous Coward]

Modifying encrypted data in memory would be even slower than what we have today. It's appropriate that Intel/AMD do what little they can do, and the rest of the security should come from the OS.

Re: Variants - never

[Anonymous Coward]

I disagree. SMT flaws should be solved by getting rid of SMT altogether and using asymmetric performance cores, which would require OS support. Basically you have 8 cores of which 6 are performance and two are low-power by default. To prevent what happened with SMT, you instead allow the low power cores to spin up to full power if the system needs it, where as the high power cores only switch between ON and OFF. So when the system is supposed to sleep, the low power cores handle all the background tasks, while performance tasks are paused. When the system is awake, the power cores handle only the foreground tasks.

SMT has only ever been used to split ALUâ(TM)s which in theory gains you 20% performance in heavily threaded tasks, but kills performance by 50% which is what the mitigation is doing.

Re: Variants - never

[Anonymous Coward]

SMT isn't the source of the Spectre/Meltdown issues, though it causes similar issues. Ryzen processors have a mitigation against SMT hacks, in that each process is coded to a specific thread in memory, but SMT still probably makes anything in memory somewhat accessible to all the processors. You could link a thread to specific memory, but this would be really wasteful due to all the copy of the data.

Modern ARM processors uses BIG.little, that you basically described, and they are still at risk for speculative execution hacks, that Spectre/Meltdown are a kind of. The speed benefit of speculative execution will be hard to abandon.

Your modifications will have no benefit to anything.

this is the wrong call

[drinkypoo]

Distributions should handle this for everyday users, so they don't have to care. People who accidentally install a kernel should get safe defaults. Defaulting to insecure is wrong.

Re:this is the wrong call

[110010001000]

If you accidentally install a kernel then I doubt you care about security. If you care about security, don't run intel, or disable Intel's insecure SMT implementation.

Re:this is the wrong call

[drinkypoo]

If you care about security, don't run intel

I don't, but this isn't about me. Or at least, it's not about me at home. It doesn't really matter anyway, because basically nobody will ever install this kernel, but the principle stands.

Re:this is the wrong call

[Anonymous Coward]

I think that this requires more than a reflexive response. As someone who is running physics simulations (albeit under FreeBSD), I do not want the default install to be 'slow', although my response would be the opposite if I was doing my banking on that computer or if I was a dissident in 90% of the globe. And the first solution that comes to mind (ask the user when installing a distribution or updating the kernel) also has obvious issues (scaring/confusing the user by asking them to choose between 'slow' and 'secure', especially when both are relative).

Re:this is the wrong call

[110010001000]

Most companies will use this kernel. Although Spectre is bad, it isn't an issue in many workloads. The vast majority of Linux servers wouldn't be affected by Spectre in reality.

Re:this is the wrong call

[drinkypoo]

Most companies will use this kernel.

I don't think they will. There is supposedly another fix coming soon, so I think they'll just skip it and either bide or revert until the next kernel comes along.

Re:this is the wrong call

[Anonymous Coward]

That someone doesn't "care" about security doesn't mean they shouldn't get secure defaults, to the contrary.

It's not *just* about those users either (who "don't care", is in "are yet unaware of X because they're still too busy with all the other shit devs and corporations sling at them"), it's also about them being a vecor of attack / resource drain on yet others.

Re:this is the wrong call

[110010001000]

There is no fix for Spectre, only mitigations.

Re:this is the wrong call

[aliquis]

I agree one shouldn't ship in an insecure state (possibly locally like if granting video and audio access require extra permissions / could be locked down then I'm fine with that being usable from the start) but I'm well aware most distributions and operating systems doesn't do so.

I used to use the BSDs quite often and then installed Fedora or something and for root password I used "ok" because whatever just that the machine ran SSH and allowed remote root logins by default. I guess someone may find that "convenient" but I don't see why it should be that way by default. (I don't think SSH need to run by default (unless the alternative is to run telnet by default instead :D) either but at-least with a username you've got obscurity.)

Re:this is the wrong call

[thegarbz]

People who accidentally install a kernel should get safe defaults. Defaulting to insecure is wrong.

People need to take an axe to their cable modem and only go on the internet once they have a degree in Computer Science majoring in security and risk assessment.

I mean I assume you're okay with booting the entire world off that dangerous internet. You've said you're happy with crippling performance for an incredibly low risk that hasn't been shown to be exploited anywhere in the public, so clearly you support throwing out the baby with the bathwater on security right?

Re:this is the wrong call

[Anonymous Coward]

Linux does lots of things (e.g., delaying writes to disk) in order to be "faster". It's just the philosophy of the distro that matters; some of them actually know their target user base. Some are even sensible, knowing full well that will cause their distro to be looked upon as retarded or old fashioned. There's hundreds, pick one, learn it and move to one that lets you have the level of control with which you're comfortable. Linux users switch distros every few weeks anyway, what's the problem?

Re:this is the wrong call

[drinkypoo]

People who accidentally install a kernel should get safe defaults. Defaulting to insecure is wrong.

People need to take an axe to their cable modem and only go on the internet once they have a degree in Computer Science majoring in security and risk assessment.

What? Put down the crack pipe, me laddo.

I mean I assume you're okay with booting the entire world off that dangerous internet.

You, and umption.

You've said you're happy with crippling performance

at boot time, and by default, but can be disabled

for an incredibly low risk that hasn't been shown to be exploited anywhere in the public

Oh, how cute. You're planning only for today. Go ahead, karma, show him what he's won.

Re:this is the wrong call

[drinkypoo]

That someone doesn't "care" about security doesn't mean they shouldn't get secure defaults, to the contrary.
It's not *just* about those users either (who "don't care", is in "are yet unaware of X because they're still too busy with all the other shit devs and corporations sling at them"), it's also about them being a vecor of attack / resource drain on yet others.

Exactly this. I couldn't have said it better myself (as evinced by the fact that I didn't) but it's actually more important for people who don't care about security to get secure defaults, specifically because they don't care.

Re:this is the wrong call

[gweihir]

I agree. But Linus is the big-picture guy here, so I can accept that he has overriding concerns. Personally, I do not even have a CPU that does SMT, as it is a pretty bad technology anyways.

Re:this is the wrong call

[jmccue]

If you care about security, don't run intel, or disable Intel's insecure SMT implementation.

Correct, OpenBSD defaults to disabling SMT and they stated some hardware there is no option to disabled SMT. So having an option in Linux to disabled SMT is probably all that is needed. Seems Linux is jumping through hoops to fix hardware issues that seem to never have an end.

Re:this is the wrong call

[110010001000]

That might be true for Windows/Mac and desktop endusers, but the vast majority of Linux systems affected are going to be servers which administrators "care" about. There is no reason to kill performance on servers which aren't running arbitrary code. Most likely desktop Linux distros will be running with the mitigations, but the number of desktop users is very small.

Re: this is the wrong call

[bn-7bc]

Ok I know performane is important, but shuld a disc write realy return before the bits are actuaky safly on disc (i mean writen nor on an on device cache) otherwise how can the calling code, and ultimatly the user, know what is written and not? Is is obvioushereIâ(TM)m norat all an expert on this so Iâ(TM)m sure Iâ(TM)m missing somthing obvius, any input is greatly apreciated.

Re:this is the wrong call

[HiThere]

There are fixes for Spectre...but they require redesigned hardware.

Re: this is the wrong call

[buchanmilne]

"So having an option in Linux to disabled SMT is probably all that is needed. "

You do know that (boot with the noht flag) has existed since hyperthreading support landed, right? Or you can compile a kernel without hyperthreading support.

Re:this is the wrong call

[jaymemaurice]

If the Linux default kernel options compiled in such a way that it turned your computer into a toaster, it shouldn't matter.
Pretty much every distro provides their own customized build and releases it through their own package management system.
A distro designed for use in toasters should be mindful of what features, patches and mitigation apply to them... conversely a server or desktop flavor should have specific applicable tuning. If you are running the wrong distro, that's another topic.
The job of a developer is to code with flexibility enabling or supporting the use cases of the hardware or software in it's ecosystem.
Also, disabling SMT globally is probably stupid. If you are concerned timing attack vectors from SMT in a particular application or in kernel space, you can mitigate such issues using CPU scheduling options such as isolcpus which will still allow you set the affinity of some SMT optimized applications onto a shared core. The operating system or hypervisor should be the broker of the memory or CPU resources when you are working with a hypervisor or operating system that properly supports it.

Re:this is the wrong call

[thegarbz]

at boot time, and by default, but can be disabled

Exactly as I said. People by default should not be allowed on the internet right? I mean it's a security risk that is many orders of magnitude worse than what you are proposing as a default.

Oh, how cute. You're planning only for today.

Nope. We're analysing the risk that is presented and the possible ways it could be exploited with a very clear answer. It won't be, not on a desktop computer, because while you're kicking yourself to close security holes I'm sending emails to your mother claiming I'm Microsoft and due to a problem on her computer she should run an executable.

There's a good reason the vast majority of malware targets users rather than esoteric and hard to exploit bugs.

Protip: The sky isn't falling, and you'd realise that if you do a risk assessment rather than just shout about expensive defaults from the mountaintops.

Re: this is the wrong call

[jmccue]

No I did not know about 'noht', thanks I have not been paying attention kernel/parms flags since the 1.x days, never needed to compile a kernel since then. :)

Hyperthreading going away

[Anonymous Coward]

9th gen core i7 losing hyperthreading anyway, Intel realizes that the only way to be safe to to eliminate hyperthreading. The real solution has always been to turn off hyperthreading. So many fixes have already been proving to be flawed and exploited, which is why some are implementing just disabling hyperthreading through the OS.

Re:Hyperthreading going away

[Anonymous Coward]

Removing HT from less expensive CPUs has nothing to do with security. They just want to add artificial new market segments, so they can sell the same shit for different prices. As they have stopped any R&D and kicked out their engineers, they can not add new features or performance improvements anymore, all they can do is to disable existing features.

Elitist idiocy

[Anonymous Coward]

"So why do that STIBP slow-down by default when the people who *really* care already disabled SMT?"

Because the people who have the chops to care are different from the people who are running computers, and the people who are damaged by botnetted computers are mostly different from the people who own the botnetted computers. Botnets are used for attack not for suicide.

Linus thinks he can pass the buck but he really is just dropping it.

Performance

[Anonymous Coward]

Under what circumstances does performance go down by 50%? Is this mostly a server issue, or does it affect some desktop users as well? And if it does affect desktop users, which ones? Everybody, or just those doing video editing or high-end gaming (if anyone does that under Linux)?

Re:Performance

[Anonymous Coward]

When using the kernel with with the spectra/meltdown fix my 10 year ThinkPad W500 with core 2 duo P9700@2.8GHz {32k-L1, 6M-L2} went from a performance of a 2017 i3 to a performance of less than a 2008 Pentium 4. The specra/meltdown fix flushes the cache every cycle so that large 6M-L2 becomes useless.

Re:Performance

[Anonymous Coward]

What type of application? Did you actually measure it, or are you just spouting off?

Re: Performance

[Anonymous Coward]

I have spent the past few years developing a genetic algorithm to solve a particular problem. It takes about 2 days to get a solution running 8 concurrent processes. I chose 8 processes because thatâ(TM)s the number that pegged my cpu at 100%. After the âfixesâ(TM), it takes only 4 processes to peg the cpu. Iâ(TM)d call that 50% degradation.
I wish there were a Turbo Switch I could install to get my performance back when I take my machines offline. Itâ(TM)s sickening that I build these state of the art machines, only to now have 50% of the capability.

Is security _all_ that matters?

[Anonymous Coward]

Linus made a point here, however, I think even he is wrong.

Would people be happy working on a 486 architecture that is 100% safe? (let's pretend 100% safe exists for the sake of the argument). I'd rather get things done quickly than spend part of the afternoon to complete just one of the jobs I'm meant to do. Would you spend, say, 10 times more to complete your jobs in a totally safe system as opposed to complete them much faster in a system that is quite safe, but not 100%?

And now where Linus gets it wrong. SMT _does_ improve performance specially in data crunching pipelines (interestingly what I do for a living). Disabling it may well help me be safer, but I would loose ~40% performance (just ran some quick tests with sysbench). Sure, writing software does not demand much hardware. Vim/NVim/Kakoune do the jobs rather well. But when you write code that also requires performance given the volume of data the user (me) works on... SMT can have a significant impact. So is not as simple as just disabling SMT.

Probably all that's needed is a bit of common sense when it comes to download software?

If security is all that matters... why don't you/we/they live in bunkers? Because most properties are fairly easy to break into. Throw a stone to a glass and there's a way in, a bunker would _never_ have that problem... specially because they probably don't even have windows. Not to mention trespassing: gardens, backyards... all they need is to jump in. That problem would never exist in a bunker. However, living in a bunker is pretty inconvenient, isn't it?

Re:Is security _all_ that matters?

[110010001000]

Um, Linus never said that SMT didn't improve performance. He just said that people who care about that level of security have already disabled it, so why make bother ruining the performance for people who don't care?

Re:Is security _all_ that matters?

[gweihir]

Also take into account that this comment is mostly targeted at virtualized server loads, not desktop computing. While there are these scenarios of "JavaScript in the browser steals your keys", the actual threat is "VM1 steals the keys of VM2", for various reasons. My prediction is that SMT will basically be dropped by CPU manufacturers. AMD was never very keen on it and Intel is currently reversing their propaganda on how great it is.

Re:Is security _all_ that matters?

[110010001000]

Sometimes I think you are the only sensible person left on the site. I know I am not!

Re:Is security _all_ that matters?

[Anonymous Coward]

What would be the impact on power consumption if SMT goes away?

Re:Is security _all_ that matters?

[gweihir]

Thanks ;-)

Re:Is security _all_ that matters?

[Anonymous Coward]

Thanks ;-)

You two can 69 and suck each other's dicks! Can I watch?!

Re:Is security _all_ that matters?

[Anonymous Coward]

https://www.tomshardware.com/reviews/hyper-threading-core-i7-980x,2584-9.html

That one is a bit old, but the quickest I found. Essentially, with HT the power consumption is a bit lower, but no _that_ lower. The impact on performance, tho, is a lot sharper.

Exactly. I thought Linux had my back.

[Anonymous Coward]

Of course I do really care.
But I assumed the Linux kernel developers did too!
Hence I thought in the case of speed VS security, they would act like a life-support machine developer, not like a "AAA" offline game developer.

Now I know that those who "really care", better switch to BSD.
Thanks Crack Groan-Arseman!

Re: Exactly. I thought Linux had my back.

[Anonymous Coward]

what does bojack horseman have to do with this?

So, disable SMT, then what? Ponies?

[Anonymous Coward]

What impact will that have on the typical workloads seen by users?
What impact will it have on virtualization seen in many common software these days, including most web browsers?
Will it essentially turn a fairly typical processor of today in to something no better than a gaming computer of 2005? Or is it massively overblown?
While I have done some multithreaded work, it was extremely basic, so I don't know for certain how good it is.
I do know that there are plenty of tasks impossible to accelerate because they require to be done in order, step after step. But I also know there is a fuckload of things that can be done in parallel.
What I don't know is the extent of developers taking advantage of it outside of browsers and high-end games.

Is there any actual DECENT solid benchmarks on workloads and comparisons to how much performance is lost that isn't a percentage.
Percentages and scores are worthless metrics when it comes to performance because there is no such thing as A single performance measure. (even though many continue trying to do such a stupid thing, including Microsoft with their dumb computer scores)
A lot of stuff I have seen over the months has been a lot of PANIC and FUD , also a lot of shitposting over Intel VS AMD.

Re:So, disable SMT, then what? Ponies?

[Anonymous Coward]

There you have one: https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1

and another, comparing the reverted code with a new approach that impacts a lot less in performance: https://www.phoronix.com/scan.php?page=article&item=linux-420wip-stibp&num=1

Re:So, disable SMT, then what? Ponies?

[110010001000]

How would you express performance loss? Percentage by workload is the only meaningful measure. What are you looking for?

Huh? Did you ever use GEOS?

[rsilvergun]

on a base model (64kb) C64? You kids today and your "slow" computers...

Seriously though, just pop a command window or the text version of emacs up (which is more or less the experience on your C64) and you'll find it plenty responsive. OTOH pull up 20+ browser tabs, run a compile and a video encoder in the background and maybe throw in some crypto currency mining and a bittorrent client for fun and yeah, you might occasionally see some lag on a window change.

I think we're asking for a bit much from our computers at times. Still, if it bother's you then buy a newer CPU, spend $200 bucks on a mobo and another $200 on 32GB of ram and $300 on your SSD. My bro did and that was that. It's not an insurmountable problem, it's not even that expensive (my C64 was $300 in 1992, that's almost $600 today and the monitor was probably another $150 at least, I can't remember). Again, kid's these days...

Re:Huh? Did you ever use GEOS?

[Anonymous Coward]

kid's these days...

And old farts who think you can get 32GB of RAM for $200.

Re:Huh? Did you ever use GEOS?

[Anonymous Coward]

you can at newegg. $150 ddr3, and $209 for ddr4

intel pay them off to not really slow there chips

[Joe_Dragon]

intel pay them off to not really slow there chips down

Re:intel pay them off to not really slow there chi

[Anonymous Coward]

Probably not.

Intel does, however, pay a whole heap of kernel developers. This is one of those situations where this has shown itself to be less than ideal, as witnessed by the initial patch for Meltdown, which at first tried to push every x86 manufacturer under the bus to save Intel's bacon. Have a looksie in the archives, and you'll find it took quite some push-back to stop that.

This is the real danger, not any vendor running around corrupting distributors.

Re:So, disable SMT, then what? Ponies?

[kobaz]

I believe the proper metric he's looking for is furlongs per fortnight.

Re:So, disable SMT, then what? Ponies?

[Anonymous Coward]

I believe the proper metric he's looking for is furlongs per fortnight.

Do you mean Furries per Fortnite?

Hardware = software

[goombah99]

These days hardware is software. e.g. management engine, things that fix cosmic rays, race conditions, microcode, .....)

4.20 blaze it!

[Anonymous Coward]

Yo!

LOL

[Anonymous Coward]

You seriously made me laugh. :)

Re:intel pay them off to not really slow there chi

[Anonymous Coward]

There was no pushback. AMD literally had to call out Intel on their bullshit (LKML) and even then the High Order in the Church of Linux, are STILL trying to make this go away. Intel has dumped a tonne of cash at high value developers and PR. If the Washington Post can make Linus take a months vacation, Intel can turn everyone else against him.

Short version is the people who are "fixing" this, are the last ones who should to be involved in validation. Their quite comfortable lives depend on it. Intel has no upgrade path, certainly not at the scale of Enterprises thus they are doing nothing but trying to delay this as much as possible until they do.

Why on Earth are changes going into the Kernel that are neither backed by data showing their impact (net or loss), nor even vetted? The infrastructure is there ffs.

Re:intel pay them off to not really slow there chi

[Anonymous Coward]

I'd call AMD outright calling bullshit on your shenanigans as a bit of a pushback. I think there where more, but maybe I'm misremembering. I remember thought that the behaviour didn't create anywhere near the stink it should have.

Either way, the whole situation has neatly exposed one of the fundamental problems with the latent conflict of interests within open source where developers have become beholden to the various OEMs. To most people ethics is great as long as it's not their paycheck which is on the line. This is why I've always been a bit skeptic about vendors outright paying developers for working on infrastructure. It's great as long as no single party holds enough sway to impede their competitors and their interests in general are aligned with the interests of the project. But the moment any of these aren't true any more, things usually goes horribly wrong.

Linux is the gateway drug

[Anonymous Coward]

Linux is the gateway drug of the Open Source narcotic. How many people have been 0wned immediately after they ran Linux? It is in Linux's best interest to keep those new users safe. Otherwise the Linux Operating System will get a worst reputation than it already has. Best of luck.

Re:So, disable SMT, then what? Ponies?

[q4Fry]

Slugs per acre, mate. That's proper pressure for you. Alternatively, an indication you're a shit gardener.