Comment by OskarS | Hacker News Reader

Comment by OskarS | Hacker News Reader

Parent Full thread

Yeah, me too, I found that pretty shocking actually. So shocking that I basically didn't believe it, so I tried myself (in C++, but it doesn't really make a difference). With 2000 threads, the computer had no problem whatsoever, the process only took around 16 megabytes of memory and not very much CPU.

So I bumped it up to 20,000, thinking that would probably work as well: the computer immediately crashed and rebooted. I didn't even get the "kernel panic" screen, it just died (this is on a 2018 mac mini with a 3.2 Ghz Core i7). When it turned back on, this was the first line of the error message:

Panic(CPU 0, time 1921358616513346): NMIPI for unresponsive processor: TLB flush timeout, TLB state:0x0

Weird. I really thought that this wouldn't be an issue at all. And: if it was an issue, that the OS would be able to handle it and kill the process or something, not kernel panic.

Yeah, that’s pretty worrying that the OS just punts. I always thought limiting the potential damage a user space process could do was one of the main jobs of an OS.

If you have any more OSes laying around to run the test on, I’d be interested to hear how well windows and Linux handle the same thing.

Because on the face of it this seems like a serious bug in the OS. I’m only used to seeing this sort of thing with bad drivers

I just tested this on my Linux workstation.

2000 threads does nothing - everything's still responsive, and the process is shown as using 0% of the CPU.

16,000 threads uses ~30% of a core, with a ~136MB RSS. The system still handles it fine, though, and everything stays responsive.

At 20,000 the program panics when spawning threads, with the message "failed to set up alternative stack guard page" due to EWOULDBLOCK. I'm not sure exactly what limit it's hitting, though.

Sounds like it's having trouble allocating memory for the stack and stack guard. Whatever limit it's hitting though, Linux seems to be able to handle it correctly, which is to kill the process instead of a kernel panic.

Thanks, much appreciated.

That’s the sort of thing I expect - the OS starves the program, not the other way around.

Reply on news.ycombinator.com