You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.
It would be nice if HaLVMs could use all the cool parallel stuff from the mainline of GHC, by utilizing multiple Xen VCPUs.
I think this is not actually all that difficult. In this case, when we boot up, we would figure out how many VCPUs we had been given and pass the appropriate number through the built-in command line. "Starting a new OS thread" then becomes booting an auxiliary processor. The big issue, really, is rewriting the locking structures that the GHC runtime expects of its threaded runtime.
Once the basic support for SMP HaLVMs is in place, we would also have to strongly consider just removing support for non-threaded-runtime versions of the HaLVM.
The text was updated successfully, but these errors were encountered:
It would be nice if HaLVMs could use all the cool parallel stuff from the mainline of GHC, by utilizing multiple Xen VCPUs.
I think this is not actually all that difficult. In this case, when we boot up, we would figure out how many VCPUs we had been given and pass the appropriate number through the built-in command line. "Starting a new OS thread" then becomes booting an auxiliary processor. The big issue, really, is rewriting the locking structures that the GHC runtime expects of its threaded runtime.
Once the basic support for SMP HaLVMs is in place, we would also have to strongly consider just removing support for non-threaded-runtime versions of the HaLVM.
The text was updated successfully, but these errors were encountered: