Windows 10 Process-Termination Bug Slows Down Mighty 24-Core System to a Crawl

[trparky]

out of curiousity, I'm going to try killing a single processes that uses over 10 GiB of memory...

That would be interesting. I would like to see the source code used to do that.

 

[FordGT90Concept]

I used a program I wrote a year ago to create and attempt to solve number mazes. Grid sizes larger than 9x9 are almost guaranteed to fill 16 GiB of RAM with 8 threads (what I have installed). Every cell it explores, it saves in memory along with all the previous cells it explored. On top of that, it branches everywhere it can making sure it never double backs on itself. Memory use is often exponential compared to the grid size.

 

[OneMoar]

its because killing one process there is no delay the issue is when you have a 1000 waiting on the same lock

 

[trparky]

I used a program I wrote a year ago to create and attempt to solve number mazes. Grid sizes larger than 9x9 are almost guaranteed to fill 16 GiB of RAM with 8 threads (what I have installed). Every cell it explores, it saves in memory along with all the previous cells it explored. On top of that, it branches everywhere it can making sure it never double backs on itself. Memory use is often exponential compared to the grid size.

You could in theory do that by creating several IO.MemoryStreams and loading huge files into them thus keeping the data in RAM.

I have used IO.MemoryStreams to keep data in RAM until the data is ready to be written to disk.

 

[OneMoar]

think of it this way you have a 1000 people waiting to jump off a bridge at the middle of the bridge there is a man with a you-may-jump stamp he can only stamp one person and a time and nobody may jump until they get there stamp

so everything grinds to a halt while one person at a time gets stamped backing up traffic and such for miles

once everybody gets there stamp they are free to leap to there impending entertainment/doom

 

[FordGT90Concept]

its because killing one process there is no delay the issue is when you have a 1000 waiting on the same lock

That's the point: no one should ever be trying to kill 1000 processes at once. Microsoft is likely going to tell Google they need to multithread their process instead of spawning lots of processes. It's an all-around better approach.


I think what is likely happening is that there's a process destruction queue. Everytime Process.Kill is called, a lock is put in place as the new kill order is enqueued. The queue can't carry out it's work (because it keeps getting locked) until the all of the kill orders have been enqueued. At which point, the lock clears and the queue is executed killing all of the processes in less than a second. The issue isn't all that, the issue is the mouse hangs in the process (probably user32.dll). I think only Microsoft knows why the two are related.


I kind of want to drag out my old Vista laptop and see what happens on there. Problem is, it only has 2 GiB of RAM.

 

[OneMoar]

That's the point: no one should ever be trying to kill 1000 processes at once. Microsoft is likely going to tell Google they need to multithread their process instead of spawning lots of processes. It's an all-around better approach.

good luck with that

this is a edge case anyway something doesn't come up in normal operation unless you are A: a really terrible programmer or B: attempting to force the issue

if you need anouther example of this: GTA:V alt-tab it and watch the entire system die

 

[HopelesslyFaithful]

That's the point: no one should ever be trying to kill 1000 processes at once. Microsoft is likely going to tell Google they need to multithread their process instead of spawning lots of processes. It's an all-around better approach.


I think what is likely happening is that there's a process destruction queue. Everytime Process.Kill is called, a lock is put in place as the new kill order is enqueued. The queue can't carry out it's work (because it keeps getting locked) until the all of the kill orders have been enqueued. At which point, the lock clears and the queue is executed killing all of the processes in less than a second. The issue isn't all that, the issue is the mouse hangs in the process (probably user32.dll). I think only Microsoft knows why the two are related.


I kind of want to drag out my old Vista laptop and see what happens on there. Problem is, it only has 2 GiB of RAM.

lol...so the answer to bad coding/design is...well you shouldnt do that anyways so no reason to fix a bad design since it should normally not be happening anyways.

genius. Since no one should have more than 10 programs open we don't need 64 bit. or multi CPUs...moron.

 

[OneMoar]

lol...so the answer to bad coding/design is...well you shouldnt do that anyways so no reason to fix a bad design since it should normally not be happening anyways.

genius. Since no one should have more than 10 programs open we don't need 64 bit. or multi CPUs...moron.

do you have any idea what you are talking about ?
do you even understand what the problem is and why/when it can happen

OR
you just gonna keep spewing windowz is teh suckz all day ?

the only moron here is you

 

[FordGT90Concept]

lol...so the answer to bad coding/design is...well you shouldnt do that anyways so no reason to fix a bad design since it should normally not be happening anyways.

genius. Since no one should have more than 10 programs open we don't need 64 bit. or multi CPUs...moron.

This 1000 process test is dangerous close to a forkbomb which is used to execute denial of service attacks and otherwise shutdown a system (any system). Processes, even doing virtually nothing, require a significant amount of memory. Threads, on the other hand, require very little.

Let's say average memory consumption for a simple process in a modern OS is 20 MiB. 1000 processes translates to 20,000 MiB or 20 GiB. Most systems don't have that much RAM installed. Spawning another thread, on the other hand, takes maybe 0.5 MiB per thread--40 times less. You can accomplish the same amount of work with 500 MiB of RAM using threads versus 20,000 MiB of RAM using processes. It really isn't a choice.

That program I demonstrated, with a little tweaking, could literally make a 1000-core system run at 100%. It won't cause the OS to hang when closing either.

 

[OneMoar]

This 1000 process test is dangerous close to a forkbomb which is used to execute denial of service attacks and otherwise shutdown a system (any system). Processes, even doing virtually nothing, require a significant amount of memory. Threads, on the other hand, require very little.

Let's say average memory consumption for a simple process in a modern OS is 20 MiB. 1000 processes translates to 20,000 MiB or 20 GiB. Most systems don't have that much RAM installed. Spawning another thread, on the other hand, takes maybe 0.5 MiB per thread--40 times less. You can accomplish the same amount of work with 500 MiB of RAM using threads versus 20,000 MiB of RAM using processes. It really isn't a choice.

That program I demonstrated, with a little tweaking, could literally make a 1000-core system run at 100%. It won't cause the OS to hang when closing either.

you are trying to reason with somebody that doesn't have a clue

 

[zlobby]

So much 'telemetry' in google's stuff that even Windoze can't shut it down. Keks!

 

[dalekdukesboy]

Maybe I just failed to see the sarcasm from a guy with an Intel CPU.

Or I woke up grumpy because my internet is only now back after comcast had me netless for almost a week. Take your pick.



Yes. It's not even broken in 7.

Hence....why I say FU to windows 10. I'll keep my windows 7 tyvm!

 

[sweet]

if you need anouther example of this: GTA:V alt-tab it and watch the entire system die

Just because of your weak-ass 4 cores CPU mate. Buy a Ryzen 7 and you can alt-tab all days.

The problem in this thread is different from your GTA example anyway. Also, this Google guy provided too little info. If he really did try to kill 1000 processes with consumer Win 10, the stupidity is his, not the OS. No consumer PC with Win 10 will ever need to kill 1000 processes. It's the job of servers, with a proper server OS to pair with.

 

[OneMoar]

Just because of your weak-ass 4 cores CPU mate. Buy a Ryzen 7 and you can alt-tab all days.

The problem in this thread is different from your GTA example anyway.

exactly its the same issue relating to how locks function on desktop windows

I would't buy a AMD ryzen cpu if it was the last cpu on earth

and i got news for you it happens on 6 core cpu's as well

my 4670k may be a generation old but it will still run circles around your chip in every gaming benchmark

 

[sweet]

exactly its the same issue relating to how locks function on desktop windows

I would't buy a AMD ryzen cpu if it was the last cpu on earth

and i got news for you it happens on 6 core cpu's as well

my 4670k may be a generation old but it will still run circles around your chip in every gaming benchmark

So salty lol. Also Ryzen 7 are 8 core so your point is invalid.

 

[OneMoar]

So salty lol. Also Ryzen 7 are 8 core so your point is invalid.

nope still vaild happens regardless of cpu GTA:V is one-thread bound anyway
it can use up to 6 threads(one per logical cpu) but they will only execute as fast as the master thread (cpu0)

 

[R-T-B]

No consumer PC with Win 10 will ever need to kill 1000 processes.

Developers do this a lot in builds.

Developers use consumer OSes on occasion too.

 

[OneMoar]

its less about the amount of processes and more about the time needed for it to release the lock and move onto the next process and release the lock again kill it and start over
its stalling out on releasing the lock and its causing something like a 900MS delay which is a eternity for a cpu

 

[sweet]

nope still vaild happens regardless of cpu GTA:V is one-thread bound anyway
it can use up to 6 threads(one per logical cpu) but they will only execute as fast as the master thread (cpu0)

Lol. We are talking about alt-tabing, why are you trying to prove GTA:V is one thread?? To be honest given that you are on a 4 core/ 4 thread CPU, it's hard to describe the feel of an 8 core/ 16 thread. Go grab yourself one and enjoy its smoothness, mate.

And where did you pull the 900ms from lol? You are really lightening my day, mate.

 

[OneMoar]

Lol. We are talking about alt-tabing, why are you trying to prove GTA:V is one thread?? To be honest given that you are on a 4 core/ 4 thread CPU, it's hard to describe the feel of an 8 core/ 16 thread. Go grab yourself one and enjoy its smoothness, mate.

And where did you pull the 900ms from lol? You are really lightening my day, mate.

think what you want kid

 

[sweet]

think what you want kid

Oh, so it's name calling time?

So much for "running circles in every gaming benchmarks", lol.

Take my advice. Next time if you alt tab and get massive slow-down, please think about changing your CPU. Even the console peasants have 8 cores, why your master race machine has only 4? Think about it and if you have money to spend and don't like AMD, no one would stop you from buying the shiny 4 cores i7, at least it is better than your current 4670k

 

[jaggerwild]

Why is this on "HeadLines"? Look like a bunch of bozos, but hey......

 

[Boosnie]

I don't get why some people have called BS on the Goma compiler.
You can't hope to run a biuld process relying on threads only.
When the linker starts reading all the stuff it has to, threads will start to compete heavly with each other, no matter how much effort you put into careful programming.
That said, Goma is a distributed compiler; the supervisor needs processes to keep track of various networked machines compiling at once, not threads.
There are no other ways really.

 

[FordGT90Concept]

The problem in this thread is different from your GTA example anyway. Also, this Google guy provided too little info. If he really did try to kill 1000 processes with consumer Win 10, the stupidity is his, not the OS. No consumer PC with Win 10 will ever need to kill 1000 processes. It's the job of servers, with a proper server OS to pair with.

Server 2012 R2 does the same.

Developers do this a lot in builds.

Developers use consumer OSes on occasion too.

My guess is he had 48 processes (one per logical core) running that were killed at once. He noticed the 125 ms hitch and investigated by trying 1000. 48 is a lot; 1000 is crazy. Visual Studio only uses 4 or 5 processes usually.