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

Spectre mitigations murder userspace performance

robert.ocallahan.org

Post reply on HN
Print view View original

281–290 of 294 posts

Re: Spectre mitigations murder userspace performance

#281

Post by teddyh »

wizzwizz4 wrote: post #133
teddyh wrote: post #91

Earlier quoted context omitted.

> “Close browser tab” - immediately exits a Google Meet. How would you know? Or, put another way: Why don’t you want to trust Google Meet, but apparently want to trust Google Chrome?

Meet isn't much integrated into Chrome, so absent a Chrome bug, closing Meet stops running Meet code, so stops the meeting. “Closing” Zoom relies on Zoom detecting the closure and stopping the meeting. It's not about spying from the software authors (having these softwares on your computer makes that impossible to defend against), but about knowing whether the people you were just talking to still have access to your…

> Meet isn't much integrated into Chrome

Again, how would you know that? There is no reasonable way you could possibly know that.

Re: Spectre mitigations murder userspace performance

#282

Post by binarybanana »

saati wrote: post #261
staticassertion wrote: post #223

Earlier quoted context omitted.

Yeah that should be really fast, still. Programs could also opt to just tell the OS "hey don't check this system call from me", on each system call, avoiding any lookup. The impact of TLB flushing, not just the cost of the flush, is really significant - it's going to take a lot of work to be as expensive within the syscall path.

What would stop malware telling the os to not check it?

Nothing, but that only makes reading the malware's memory possible with these exploits. That malware won't be able to access memory of some other process, if that other process is using those flags itself.

Edit: For that to work that flag would have to work on the context switch level. So every time you switch away from a sensitive process, flush all buffers and whatever else, then switch. This also requires the kernel itself to enable mitigations as necessary when it touches encryption keys before switching back to user space.

Re: Spectre mitigations murder userspace performance

#283

Post by dsp »

emilfihlman wrote: post #277
dsp wrote: post #236

Earlier quoted context omitted.

> having the kernel execute consecutive systemcalls without switching the context io_uring enables exactly this https://kernel.dk/io_uring.pdf

Only for io, which is not the same thing.

Despite the name, there is nothing io-specific about the io_uring interface. Non-io syscalls can be added. Io syscalls just tend to benefit the most (due to call frequency).

Re: Spectre mitigations murder userspace performance

#284

Post by Abishek_Muthian »

dijit wrote: post #14
neilsimp1 wrote: post #2

`mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable Spectre/Meltdown mitigations, in case anyone is wondering. This page has a pretty decent write-up on it: https://leochavez.org/index.php/2020/11/16/disabling-intel-a... .

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

> I love that this is a toggle like this, having control of my system is why I love Linux.

The need to keep telling this loud and clear for the manufacturers to hear is more needed now than ever since computers are becoming closed systems like smartphones and Manufacturers are claiming 'Customers not having to make hard decisions' to do so.

Re: Spectre mitigations murder userspace performance

#285

Post by SAI_Peregrinus »

Popegaf wrote: post #278
dkarras wrote: post #270

Earlier quoted context omitted.

I'm not sure if I got you right: The performance boost with speculative execution is massive. It introduces a vuln. It is the fix for that vuln that kills the performance.

What I'm saying is if the fix for the vuln negates the performance boost from speculative execucution, then the net outcome is 0 performance boost and speculative execution might as well be removed entirely. It wouldn't surprise me if it just costs more energy to keep the vuln and mitigation active at the same time.

The fix doesn't negate the performance boost. It decreases it. But it's still nonzero boost.

Re: Spectre mitigations murder userspace performance

#286

Post by staticassertion »

saati wrote: post #261
staticassertion wrote: post #223

Earlier quoted context omitted.

Yeah that should be really fast, still. Programs could also opt to just tell the OS "hey don't check this system call from me", on each system call, avoiding any lookup. The impact of TLB flushing, not just the cost of the flush, is really significant - it's going to take a lot of work to be as expensive within the syscall path.

What would stop malware telling the os to not check it?

That assumes that the malware can already have arbitrary control over system calls, at which point spectre isn't the issue.

Re: Spectre mitigations murder userspace performance

#287

Post by quotemstr »

emilfihlman wrote: post #276
quotemstr wrote: post #232

Earlier quoted context omitted.

> Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace. io_uring already gives you that. You can submit multiple operations in a batch and link the operations together so that if one operation in a chain of linked operations fails, io_uring won't try to execute the rest.

Which is not syscall chaining, but message chaining, of io.

Huh? It is literally system call chaining. You can make many system calls via io_ioring.

Re: Spectre mitigations murder userspace performance

#288

Post by davidwf »

jodrellblank wrote: post #106
lumost wrote: post #89

Earlier quoted context omitted.

has there been any research on what hardware changes would be necessary to reclaim performance? I've noticed extreme stutter events on desktop OSX for the last 2 years. Would be curious if its related.

Seems like there’s a lot of people with stuttering macOS https://apple.stackexchange.com/questions/245429/cursor-free... USB-C and USB 3.0 devices are one common cause, Bluetooth mouse interference by USB another, and external monitors after sleep/wake another.

I know this is random but my Bluetooth mouse was driving me absolutely nuts, and this workaround (which involves a GUI instead of running some random script off the internet) was an absolute lifesaver: https://apple.stackexchange.com/questions/377853/macos-catal...

Re: Spectre mitigations murder userspace performance

#289

Post by jfrunyon »

PedroBatista wrote: post #96
jfrunyon wrote: post #93

Here's the lesson: we hit the ceiling on our current technology a while ago. Developers continue to behave as though computing resources will continue growing as they used to, even though they've been stagnant for years.

That's not really true. I think your views are founded on the "moar Mhz moar performance" myth ( which is prevalent ), and Intel's decades old monopoly didn't help either, but if you compare 2 equivalent CPU's 10-15 years apart, there is no stagnation in performance. Maybe the old trick of cranking up the Mhz and call it a day doesn't work the way it used to, but in terms of performance results we are getting improve…

> Maybe the old trick of cranking up the Mhz and call it a day doesn't work the way it used to, but in terms of performance results we are getting improvements.

Except... we aren't. Intel's CPUs haven't gotten significantly better in 4+ generations. AMD's have, but that's only because they were still catching up to Intel.

Post reply on HN