[xemdetia]

CPU utilization is an extremely poor indicator for whether or not your system will feel stuttering or freezing. What makes your system freeze is having more tasks to complete than can be reasonably scheduled in a time frame to as to appear continuous/realtime. Most OS schedulers that I am aware of do not provide special treatment to UI processes and defer to the fact that most modern UI's require many programs to respond in a timely fashion to provide a user interface and do not assign priority unless specially instructed. Most provide (relatively) even priority and have high priority interrupts like Window's ctrl-alt-delete and higher priority to kernel threads.

In Linux actual scenarios for stuttering/freezing are generally represented as a load average >1, and stuttering for me generally starts to happen when I get above 3 and I assure you no Linux system will work without observable stutter when you start getting into the 20+ load average range.

In earnest I have no idea why you tried to use a JavaScript based benchmark to support your point. Even after observing it the number of nonvoluntary ctxt switches barely even registered from baseline, probably from the variety of ways browsers do their own internal threading strategies. I could not see how to change that JavaScript benchmark to make it actually provide an interesting load on my system, so I'll just leave it at that.

[la_barba]

I have no idea what happens under the hood in Linux, but I have never observed my Linux desktop 'crawling to a halt' because of some silly webapp. This is normal expected behavior. I know for a fact that ensuring responsiveness of GUI apps has been in the NT scheduler for decades. Look up dynamic priority groups. There is really no point rehashing and arguing over basic design issues that anyone can lookup and as such this thread is not really productive for either of us. Hope you have a nice day, Goodbye!