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

OpenBSD disables Intel's hyperthreading due to security concerns

mail-archive.com

Post reply on HN
Print view View original

51–60 of 158 posts

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#51

Post by hermitdev »

Someone1234 wrote: post #2

Ouch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available). When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.

Except the performance of hyper-threading today is far better than it was first introduced. I had a dual-socket P4 Xeon box w/ HT around 2003. Single-threaded performance with HT enabled was around 70% of what it was with HT disabled. Today, I think you'd see only about 95-98% of enabled vs disabled performance.

I don't have hard numbers to back this up, it's purely my personal experience/recollection. On my 2 socket P4 Xeon box, I disabled HT. On my current I7 6-core box, I have HT on.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#52

Post by greglindahl »

ajross wrote: post #30
mww09 wrote: post #20

Earlier quoted context omitted.

>This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for performance. Intuitively this may sound logical, however in practice it's often not the case. For many workloads putting two threads of the same program on a core ends up being worse than co…

In practice it sometimes is the case, though. SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other. If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource. On balance, on typical workloads…

Typical workloads? What's that? People run hugely diverse workloads on cpus, and they change over time.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#54

Post by mtgx »

timvisee wrote: post #36
valarauca1 wrote: post #9

Earlier quoted context omitted.

Firefox process per tab is behind a feature flag as it’s in testing still

I don't think the plan is to ever enable this in the comming few years. The current approach with a few tabs is much more memory efficient, which is why they've chosen it.

And it's a mistake.

Just recently I noticed that when Firefox loads multiple tabs of the same wordpress site, it starts hanging not unlike Firefox always used to hang. That's likely because it groups all of those same site pages under one process.

I've never experienced that with Chrome. This is why I hope Firefox eventually (ASAP) switches to one process per tab, too. I can handle the browser using an extra GB of RAM. I can't handle it hanging on me and frustrating me.

Instead of pushing for 30-40% lower memory than Chrome, I say they should push for 10% lower memory with the same sanboxed process per tab model.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#55

Post by craftyguy »

valarauca1 wrote: post #9
greglindahl wrote: post #8

Earlier quoted context omitted.

Chrome does, Firefox does not (I've got 5 processes for a billion tabs.)

Firefox process per tab is behind a feature flag as it’s in testing still

The only thing I could find is a set of 'browser.tabs.remote.*' options, that are all enabled by default in FF 60.

That seems to indicate it is enabled, since the old option was 'browser.tabs.remote'? Or has it changed to something else now?

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#56

Post by ajross »

greglindahl wrote: post #52
ajross wrote: post #30

Earlier quoted context omitted.

In practice it sometimes is the case, though. SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other. If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource. On balance, on typical workloads…

Typical workloads? What's that? People run hugely diverse workloads on cpus, and they change over time.

Building software, serving web pages, executing database queries, running a DOM layout, managing game logic... I mean, come on. You knew what I meant. Those are all tasks with "medium" cache residency and "occasional" stalls on DRAM. Anything that does a bunch of different things with a big-ish world of data.

Conversely: finding a task that is L1-cache-bound but does not frequently have to stall for memory is much harder. The only ones off the top of my head are streaming tasks like software video decode.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#58

Post by greglindahl »

ajross wrote: post #56
greglindahl wrote: post #52

Earlier quoted context omitted.

Typical workloads? What's that? People run hugely diverse workloads on cpus, and they change over time.

Building software, serving web pages, executing database queries, running a DOM layout, managing game logic... I mean, come on. You knew what I meant. Those are all tasks with "medium" cache residency and "occasional" stalls on DRAM. Anything that does a bunch of different things with a big-ish world of data. Conversely: finding a task that is L1-cache-bound but does not frequently have to stall for memory is much ha…

Oh, you meant typical for you.

One task that is L1 cache bound and does not frequently stall for memory (if you code it up well) is matrix multiply.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#59

Post by greglindahl »

mtgx wrote: post #54
timvisee wrote: post #36

Earlier quoted context omitted.

I don't think the plan is to ever enable this in the comming few years. The current approach with a few tabs is much more memory efficient, which is why they've chosen it.

And it's a mistake. Just recently I noticed that when Firefox loads multiple tabs of the same wordpress site, it starts hanging not unlike Firefox always used to hang. That's likely because it groups all of those same site pages under one process. I've never experienced that with Chrome. This is why I hope Firefox eventually (ASAP) switches to one process per tab, too. I can handle the browser using an extra GB of RA…

So, you're saying because you think you've discovered one case where there might be a problem, Firefox should completely change their architecture? And you're saying this in a discussion which frequently mentions how extremely varied workloads are?

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#60

Post by ComputerGuru »

greglindahl wrote: post #8
endianswap wrote: post #7

Earlier quoted context omitted.

Don't most browsers run one process per page/tab nowadays?

Chrome does, Firefox does not (I've got 5 processes for a billion tabs.)

No, Chrome used to but now uses a heuristic to determine whether new tabs should be launched in their own process or share an existing process, as a memory usage mitigation strategy. I believe tabs from the same origin have a preference of sharing processes.
Post reply on HN