[erlang-questions] Concurrent processes on multi-core platforms with lots of chatter
Mon Nov 30 20:45:54 CET 2009
2009/11/30 Evans, Matthew <mevans@REDACTED>
> First the good news: When running tests that do more than just message
> passing the SMP features of R13B02 are leaps and bounds over R12B05 that I
> was running previously. What I have however noticed is that in a pure
> messaging test (lots of messages, in a tight loop) we appear to run into
> caching issues where messages are sent between processes that happen to be
> scheduled on different cores. This got me into thinking about a future
> enhancement to the Erlang VM: Process affinity.
> In this mode two or more processes that have a lot of IPC chatter would be
> associated into a group and executed on the same core. If the scheduler
> needed to move one process to another core - they would all be relocated.
> Although this grouping of processes could be done automatically by the VM I
> believe the decision making overhead would be too great, and it would likely
> make some poor choices as to what processes should be grouped together.
> Rather I would leave it to the developer to make these decisions, perhaps
> with a library similar to pg2.
Process/scheduler affinity has been discussed at length before and there are
several schools of thought on the matter.
It is true that accounting and statistics gathering in the runtime has some
overhead. However, this should be handled by the scheduler. The user (the
erlang developer) might not have all the information at hand and if he
doesn't he has to collect them which also costs. It would be easier for the
system to schedule the process right. The scheduler still has collect other
information and make decisions on memory models, memory distance, number of
processing units, process to process message affinity, load balancing and
other characteristics. It would be reasonable easy to model a scheduler
algorithm after these charateristics and we can make it much more dynamic in
the runtime system.
Ideally the user shouldn't be concerned about the hardware he is running
on. Thats my take on the situation anyway.
More information about the erlang-questions