On 2008 Sep 17, at 16:44, Evan Laforge wrote:
The fast context switching part seems orthogonal to me. Why is it that getting the OS involved for context switches kills the performance? Is it that the ghc RTS can switch faster because it knows more about the code it's running (i.e. the OS obviously couldn't switch on memory allocations like that)? Or is jumping up to kernel space somehow expensive by nature? And why does the OS need so many
A context switch involving the OS is actually a double (at least) context switch: one to switch to kernel context, another to switch back to user context, and (because kernel context switches are scheduler entry points) optionally switches to other processes which have a higher immediate priority. These context switches also switch considerably more state than a user-mode context switch between green threads, which doesn't switch the full process context including the set of process page tables, processor access controls, etc. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH