| Author |
Message |
< Erlang questions mailing list ~ Concurrent processes on multi-core platforms with lots of c |
| Guest |
 Posted: Mon Nov 30, 2009 7:47 pm |
 |
|
|
Guest
|
2009/11/30 Evans, Matthew <mevans@verivue.com>
> 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.
Regards,
Bj |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Nov 30, 2009 9:51 pm |
|
|
|
Guest
|
2009/11/30 Evans, Matthew <mevans@verivue.com>
> This is one reason why I thought of something along the lines of a process
> group (Zoltan |
|
|
| Back to top |
|
| rvirding |
| Posted: Tue Dec 01, 2009 2:51 am |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
Another solution would be to use the existing process groups as these are
not really used very much today. A process group is defined as all the
processes which have the same group leader. It is possible to change group
leader. Maybe the VM could try to migrate processes to the same core as
their group leader.
One problem today is that afaik the VM does not keep track of groups as
such, it would have to do this to be able to load balance efficiently.
Robert
2009/11/30 Evans, Matthew <mevans@verivue.com>
> Hi,
>
> I've been running messaging tests on R13B02, using both 8 core Intel and 8
> core CAVIUM processors. The tests involve two or more processes that do
> nothing more than sit in a loop exchanging messages as fast as they can.
> These tests are, of course, not realistic (as in real applications do more
> than sit in a tight loop sending messages), so my findings will likely not
> apply to a real deployment.
>
> 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.
>
> For example, library process affinity (paf) could have the functions:
>
> paf:create(Name,[Opts]) -> ok, {error, Reason}
> paf:join(Name,Pid,[Opts]) -> ok, {error, Reason}
> paf:leave(Name,Pid) -> ok
> paf:members(Name) -> MemberList
>
> An affinity group would be created with options for specifying the maximum
> size of the group (to ensure we don't have all processes on one core), a
> default membership time within a group (to ensure we don't unnecessarily
> keep a process in the group when there is no longer a need) and maybe an
> option to allow the group to be split over different cores if the group size
> reaches a certain threshold.
>
> A process would join the group with paf:join/3, and would be a member for
> the default duration (with options here to override the settings specified
> in paf:create). If the group is full the request is rejected (or maybe
> queued). After a period of time the process is removed from the group and a
> message {paf_leave, Pid} is sent to the process that issued the paf:join
> command. If needed the process could be re-joined at that time with another
> paf:join call.
>
> Any takers? R14B01 perhaps 
>
> Thanks
>
> Matt
>
Post received from mailinglist |
|
|
| Back to top |
   
|
| kagato |
| Posted: Tue Dec 01, 2009 3:56 am |
|
|
|
User
Joined: 30 Dec 2007
Posts: 85
|
Off the top of my head, I would expect this to be a process_flag.
Something like: process_flag(scheduler_affinity, term()). Possibly with a generic group specified by an atom like undefined. This feels more functional than the proposed paf module, and has the benefit of being data-centric.
The reason I would use a term (and then group by the hash of the term) is because it gives an elegant way to group processes by an arbitrary (possibly application specific) key. Imagine if, for example, Mnesia grouped processes by a transaction ID, or if CouchDB grouped them by socket connection, etc. By not specifying it as an atom or an integer, it lets you just use whatever is appropriate for the application.
I'm not too keen on reusing process groups primarily because group leaders are used for some really common stuff like IO, which shouldn't affect affinity at all.
If we want to be really crazy, we could provide the ability to specify something like a MatchSpec to map a process group to a processor. Call it a SchedSpec. This has the added bonus that you could have multiple handlers that would match in order without having the full blown load of a gen_event or arbitrary fun. This might also provide the beginnings of more powerful prioritization than the existing process_flag(priority) we have now.
Currently, the Use Case that people seem to be concerned with is ensuring locality of execution. However, some people might also want to use it to provide dedicated cores to things like system processing. I have no idea how this would fit with things like the AIO threads, but I'm pretty sure that HPC could benefit from, for example, dedicating 1 scheduler to system management tasks, 1 core to IO, and 6 cores to computation. This is a higher bar, but it's important nonetheless.
Of course, this would have the user thinking about the underlying CPU topology (which I agree is bad). However, this is simply unavoidable in HPC, so it's best that we accept it. Let me state this emphatically, if we try to make Erlang "smart" about scheduling, what is going to happen is that HPC people will dig down, figure out what its doing wrong, then come back with complaints. We will never be able to make it work right for everyone without exposing these same tunables (but likely with a crappier interface). It's better to give them powerful hooks to customize the scheduler with smart default behavior for everyone else.
The reason I like the process_flag(scheduler_affinity) / SchedSpec option is that it can easily start out with just the process_flag, and add something like SchedSpec's later, without having to change the API (or particularly the default behavior). Basically, you get three groups of users:
* Normal People: They don't use affinity, although pieces of the system might. (effectively implemented already)
* Locality Users: They use affinity for locality using the convenient process_flag interface. (easily done with additional process_flag)
* HPC: They use affinity, and plugin SchedSpecs that are custom to their deployment. (can be provided when demanded without breaking first two groups)
On Nov 30, 2009, at 6:49 PM, Robert Virding wrote:
> Another solution would be to use the existing process groups as these are
> not really used very much today. A process group is defined as all the
> processes which have the same group leader. It is possible to change group
> leader. Maybe the VM could try to migrate processes to the same core as
> their group leader.
>
> One problem today is that afaik the VM does not keep track of groups as
> such, it would have to do this to be able to load balance efficiently.
>
> Robert
>
> 2009/11/30 Evans, Matthew <mevans@verivue.com>
>
>> Hi,
>>
>> I've been running messaging tests on R13B02, using both 8 core Intel and 8
>> core CAVIUM processors. The tests involve two or more processes that do
>> nothing more than sit in a loop exchanging messages as fast as they can.
>> These tests are, of course, not realistic (as in real applications do more
>> than sit in a tight loop sending messages), so my findings will likely not
>> apply to a real deployment.
>>
>> 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.
>>
>> For example, library process affinity (paf) could have the functions:
>>
>> paf:create(Name,[Opts]) -> ok, {error, Reason}
>> paf:join(Name,Pid,[Opts]) -> ok, {error, Reason}
>> paf:leave(Name,Pid) -> ok
>> paf:members(Name) -> MemberList
>>
>> An affinity group would be created with options for specifying the maximum
>> size of the group (to ensure we don't have all processes on one core), a
>> default membership time within a group (to ensure we don't unnecessarily
>> keep a process in the group when there is no longer a need) and maybe an
>> option to allow the group to be split over different cores if the group size
>> reaches a certain threshold.
>>
>> A process would join the group with paf:join/3, and would be a member for
>> the default duration (with options here to override the settings specified
>> in paf:create). If the group is full the request is rejected (or maybe
>> queued). After a period of time the process is removed from the group and a
>> message {paf_leave, Pid} is sent to the process that issued the paf:join
>> command. If needed the process could be re-joined at that time with another
>> paf:join call.
>>
>> Any takers? R14B01 perhaps
>>
>> Thanks
>>
>> Matt
>>
--
Jayson Vantuyl
kagato@souja.net
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| kagato |
| Posted: Tue Dec 01, 2009 4:02 am |
|
|
|
User
Joined: 30 Dec 2007
Posts: 85
|
Wait, am I confusing process groups with group_leaders? Are those the same? Even if they aren't, I still don't like repurposing pg or creating a new API.
Also, the other nice bits about the process_flag option is that:
1. It keeps the all process information together under an existing, extensible API.
2. Creating and deleting affinity groups is implicit.
3. Depending on the uniformity of erlang:phash2/2, it can be used internally to handle the ranging all in native code.
On Nov 30, 2009, at 7:54 PM, Jayson Vantuyl wrote:
> Off the top of my head, I would expect this to be a process_flag.
>
> Something like: process_flag(scheduler_affinity, term()). Possibly with a generic group specified by an atom like undefined. This feels more functional than the proposed paf module, and has the benefit of being data-centric.
>
> The reason I would use a term (and then group by the hash of the term) is because it gives an elegant way to group processes by an arbitrary (possibly application specific) key. Imagine if, for example, Mnesia grouped processes by a transaction ID, or if CouchDB grouped them by socket connection, etc. By not specifying it as an atom or an integer, it lets you just use whatever is appropriate for the application.
>
> I'm not too keen on reusing process groups primarily because group leaders are used for some really common stuff like IO, which shouldn't affect affinity at all.
>
> If we want to be really crazy, we could provide the ability to specify something like a MatchSpec to map a process group to a processor. Call it a SchedSpec. This has the added bonus that you could have multiple handlers that would match in order without having the full blown load of a gen_event or arbitrary fun. This might also provide the beginnings of more powerful prioritization than the existing process_flag(priority) we have now.
>
> Currently, the Use Case that people seem to be concerned with is ensuring locality of execution. However, some people might also want to use it to provide dedicated cores to things like system processing. I have no idea how this would fit with things like the AIO threads, but I'm pretty sure that HPC could benefit from, for example, dedicating 1 scheduler to system management tasks, 1 core to IO, and 6 cores to computation. This is a higher bar, but it's important nonetheless.
>
> Of course, this would have the user thinking about the underlying CPU topology (which I agree is bad). However, this is simply unavoidable in HPC, so it's best that we accept it. Let me state this emphatically, if we try to make Erlang "smart" about scheduling, what is going to happen is that HPC people will dig down, figure out what its doing wrong, then come back with complaints. We will never be able to make it work right for everyone without exposing these same tunables (but likely with a crappier interface). It's better to give them powerful hooks to customize the scheduler with smart default behavior for everyone else.
>
> The reason I like the process_flag(scheduler_affinity) / SchedSpec option is that it can easily start out with just the process_flag, and add something like SchedSpec's later, without having to change the API (or particularly the default behavior). Basically, you get three groups of users:
>
> * Normal People: They don't use affinity, although pieces of the system might. (effectively implemented already)
> * Locality Users: They use affinity for locality using the convenient process_flag interface. (easily done with additional process_flag)
> * HPC: They use affinity, and plugin SchedSpecs that are custom to their deployment. (can be provided when demanded without breaking first two groups)
>
> On Nov 30, 2009, at 6:49 PM, Robert Virding wrote:
>
>> Another solution would be to use the existing process groups as these are
>> not really used very much today. A process group is defined as all the
>> processes which have the same group leader. It is possible to change group
>> leader. Maybe the VM could try to migrate processes to the same core as
>> their group leader.
>>
>> One problem today is that afaik the VM does not keep track of groups as
>> such, it would have to do this to be able to load balance efficiently.
>>
>> Robert
>>
>> 2009/11/30 Evans, Matthew <mevans@verivue.com>
>>
>>> Hi,
>>>
>>> I've been running messaging tests on R13B02, using both 8 core Intel and 8
>>> core CAVIUM processors. The tests involve two or more processes that do
>>> nothing more than sit in a loop exchanging messages as fast as they can.
>>> These tests are, of course, not realistic (as in real applications do more
>>> than sit in a tight loop sending messages), so my findings will likely not
>>> apply to a real deployment.
>>>
>>> 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.
>>>
>>> For example, library process affinity (paf) could have the functions:
>>>
>>> paf:create(Name,[Opts]) -> ok, {error, Reason}
>>> paf:join(Name,Pid,[Opts]) -> ok, {error, Reason}
>>> paf:leave(Name,Pid) -> ok
>>> paf:members(Name) -> MemberList
>>>
>>> An affinity group would be created with options for specifying the maximum
>>> size of the group (to ensure we don't have all processes on one core), a
>>> default membership time within a group (to ensure we don't unnecessarily
>>> keep a process in the group when there is no longer a need) and maybe an
>>> option to allow the group to be split over different cores if the group size
>>> reaches a certain threshold.
>>>
>>> A process would join the group with paf:join/3, and would be a member for
>>> the default duration (with options here to override the settings specified
>>> in paf:create). If the group is full the request is rejected (or maybe
>>> queued). After a period of time the process is removed from the group and a
>>> message {paf_leave, Pid} is sent to the process that issued the paf:join
>>> command. If needed the process could be re-joined at that time with another
>>> paf:join call.
>>>
>>> Any takers? R14B01 perhaps
>>>
>>> Thanks
>>>
>>> Matt
>>>
>
>
>
> --
> Jayson Vantuyl
> kagato@souja.net
>
>
>
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
--
Jayson Vantuyl
kagato@souja.net
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| alexarnon |
| Posted: Tue Dec 01, 2009 9:24 am |
|
|
|
User
Joined: 26 Jan 2008
Posts: 14
|
+1
And then some 
On Tue, Dec 1, 2009 at 5:54 AM, Jayson Vantuyl <kagato@souja.net> wrote:
> Off the top of my head, I would expect this to be a process_flag.
>
> Something like: process_flag(scheduler_affinity, term()). Possibly with a
> generic group specified by an atom like undefined. This feels more
> functional than the proposed paf module, and has the benefit of being
> data-centric.
>
> The reason I would use a term (and then group by the hash of the term) is
> because it gives an elegant way to group processes by an arbitrary (possibly
> application specific) key. Imagine if, for example, Mnesia grouped
> processes by a transaction ID, or if CouchDB grouped them by socket
> connection, etc. By not specifying it as an atom or an integer, it lets you
> just use whatever is appropriate for the application.
>
> I'm not too keen on reusing process groups primarily because group leaders
> are used for some really common stuff like IO, which shouldn't affect
> affinity at all.
>
> If we want to be really crazy, we could provide the ability to specify
> something like a MatchSpec to map a process group to a processor. Call it a
> SchedSpec. This has the added bonus that you could have multiple handlers
> that would match in order without having the full blown load of a gen_event
> or arbitrary fun. This might also provide the beginnings of more powerful
> prioritization than the existing process_flag(priority) we have now.
>
> Currently, the Use Case that people seem to be concerned with is ensuring
> locality of execution. However, some people might also want to use it to
> provide dedicated cores to things like system processing. I have no idea
> how this would fit with things like the AIO threads, but I'm pretty sure
> that HPC could benefit from, for example, dedicating 1 scheduler to system
> management tasks, 1 core to IO, and 6 cores to computation. This is a
> higher bar, but it's important nonetheless.
>
> Of course, this would have the user thinking about the underlying CPU
> topology (which I agree is bad). However, this is simply unavoidable in
> HPC, so it's best that we accept it. Let me state this emphatically, if we
> try to make Erlang "smart" about scheduling, what is going to happen is that
> HPC people will dig down, figure out what its doing wrong, then come back
> with complaints. We will never be able to make it work right for everyone
> without exposing these same tunables (but likely with a crappier interface).
> It's better to give them powerful hooks to customize the scheduler with
> smart default behavior for everyone else.
>
> The reason I like the process_flag(scheduler_affinity) / SchedSpec option
> is that it can easily start out with just the process_flag, and add
> something like SchedSpec's later, without having to change the API (or
> particularly the default behavior). Basically, you get three groups of
> users:
>
> * Normal People: They don't use affinity, although pieces of the system
> might. (effectively implemented already)
> * Locality Users: They use affinity for locality using the convenient
> process_flag interface. (easily done with additional process_flag)
> * HPC: They use affinity, and plugin SchedSpecs that are custom to their
> deployment. (can be provided when demanded without breaking first two
> groups)
>
> On Nov 30, 2009, at 6:49 PM, Robert Virding wrote:
>
> > Another solution would be to use the existing process groups as these are
> > not really used very much today. A process group is defined as all the
> > processes which have the same group leader. It is possible to change
> group
> > leader. Maybe the VM could try to migrate processes to the same core as
> > their group leader.
> >
> > One problem today is that afaik the VM does not keep track of groups as
> > such, it would have to do this to be able to load balance efficiently.
> >
> > Robert
> >
> > 2009/11/30 Evans, Matthew <mevans@verivue.com>
> >
> >> Hi,
> >>
> >> I've been running messaging tests on R13B02, using both 8 core Intel and
> 8
> >> core CAVIUM processors. The tests involve two or more processes that do
> >> nothing more than sit in a loop exchanging messages as fast as they can.
> >> These tests are, of course, not realistic (as in real applications do
> more
> >> than sit in a tight loop sending messages), so my findings will likely
> not
> >> apply to a real deployment.
> >>
> >> 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.
> >>
> >> For example, library process affinity (paf) could have the functions:
> >>
> >> paf:create(Name,[Opts]) -> ok, {error, Reason}
> >> paf:join(Name,Pid,[Opts]) -> ok, {error, Reason}
> >> paf:leave(Name,Pid) -> ok
> >> paf:members(Name) -> MemberList
> >>
> >> An affinity group would be created with options for specifying the
> maximum
> >> size of the group (to ensure we don't have all processes on one core), a
> >> default membership time within a group (to ensure we don't unnecessarily
> >> keep a process in the group when there is no longer a need) and maybe an
> >> option to allow the group to be split over different cores if the group
> size
> >> reaches a certain threshold.
> >>
> >> A process would join the group with paf:join/3, and would be a member
> for
> >> the default duration (with options here to override the settings
> specified
> >> in paf:create). If the group is full the request is rejected (or maybe
> >> queued). After a period of time the process is removed from the group
> and a
> >> message {paf_leave, Pid} is sent to the process that issued the paf:join
> >> command. If needed the process could be re-joined at that time with
> another
> >> paf:join call.
> >>
> >> Any takers? R14B01 perhaps
> >>
> >> Thanks
> >>
> >> Matt
> >>
>
>
>
> --
> Jayson Vantuyl
> kagato@souja.net
>
>
>
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Dec 01, 2009 10:04 am |
|
|
|
Guest
|
On Tue, Dec 1, 2009 at 3:49 AM, Robert Virding <rvirding@gmail.com> wrote:
> Another solution would be to use the existing process groups as these are
> not really used very much today. A process group is defined as all the
> processes which have the same group leader. It is possible to change group
> leader. Maybe the VM could try to migrate processes to the same core as
> their group leader.
This would not work so well together with the application concept, as processes
in an application has the application master as group leader. Your suggestion
would imply that all processes in an application would be migrated to the same
core.
/H |
|
|
| Back to top |
|
| rvirding |
| Posted: Tue Dec 01, 2009 4:34 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
2009/12/1 Jayson Vantuyl <kagato@souja.net>
> Wait, am I confusing process groups with group_leaders? Are those the
> same? Even if they aren't, I still don't like repurposing pg or creating a
> new API.
>
I mean the built-in process groups which you access with the
group_leader/0/1 BIFs and *NOT* the process groups as defined using the
modules pg or pg2. There is an unfortunate name clash here by pg and pg2.
Robert
Post received from mailinglist |
|
|
| Back to top |
|
| rvirding |
| Posted: Tue Dec 01, 2009 5:08 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
I will try and answer these two messages together as the replies are linked.
2009/12/1 Jayson Vantuyl <kagato@souja.net>
> I'm not too keen on reusing process groups primarily because group leaders
> are used for some really common stuff like IO, which shouldn't affect
> affinity at all.
>
2009/12/1 H |
|
|
| Back to top |
|
| kagato |
| Posted: Tue Dec 01, 2009 11:48 pm |
|
|
|
User
Joined: 30 Dec 2007
Posts: 85
|
> This vision was never really developed and all that process groups are used
> for today is default I/O. This also means that they are very sparingly used.
I have code that manipulates the group_leader precisely to control where default IO happens and where SASL logs go. I would rather not have this break.
> - I think the fact that process groups today are used for stuff common to
> the group is something which should affect affinity. Where better to put
> stuff common to a group of processes than close to the processes?
I don't think that the current semantics of process groups can accommodate this. By doing this, you either bind logging, default IO, and affinity, or you break any code that uses group_leader to manage logging and default IO. I would imagine that the latter is pretty painful.
> - As process groups are used for very little, then they are very little
> used. There is nothing as far as I know which demands that an application is
> in only one group, it is done so today because that is sufficient for
> process groups provide. In the same way you have supervisor trees there is
> nothing which prohibits you from having group leader trees with different
> types of group leaders depending on where the group common stuff is to be
> handled; a group leader could pass on its requests up the tree until the
> right group leader is reached.
Again, we're overloading a concept. If we had keyed group leaders, this might make sense. Something like group_leader(GroupLeader,Pid,GroupKey), so you could do group_leader(Leader,self(),affinity). However, I don't particularly see this as more effective than a process_flag, and I am loathe to break any custom code for directing SASL logs or default IO. This is a *big thing*.
Another mark in favor of process_flag is that it doesn't require an arbitrary leader process. When a group_leader exits it appears from my limited testing that the processes old group_leader is still returned by the group_leader function. I'm not sure that this is the right behavior for affinity. Similarly, there may not be a suitable leader process in all situations, and tossing around extra processes for this seems like more work than necessary.
I can't imagine that this makes it any easier on the scheduling side either. Migration of a group_leader would be a big deal, as tons of processes might follow it. Allocating affine processes from a hash is a static matter with low overhead. Making group_leaders "static" doesn't really help either, as it's more interface overhead (and may create load issues unless you rebalance them, again with a hash, just like I propose with process_flag).
Again, affinity with process_flag requires one line of code per worker, ever. No processes are special, which is nice. The little bits of extra work associated with managing processes is one more thing on the pile of stuff that makes Erlang code unnecessarily verbose (which, honestly, is already quite significant).
One thing I did notice was that group_leader is explicitly inherited. This is important, because I think that's a behavior of process affinity that has been assumed, but nobody mentioned it yet. Using group_leader would definitely imply inheritance.
> I don't like the idea of adding new features to the language if there is
> something already there which could be used, the language is growing enough
> as it is, not all bad of course.
Ironically, that's the same reason I recommended process_flag. Process_flag exists already and is designed to be extensible. I didn't really see this as an added feature, so much as a completely backwards-compatible extension to an intentionally extensible interface. Unless you're talking about the feature of affinity, which is added in either case.
--
Jayson Vantuyl
kagato@souja.net
________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org
Post received from mailinglist |
|
|
| Back to top |
|
| wuji |
| Posted: Tue Aug 28, 2012 7:25 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
lecture Thursday, Oberle crossed one of two fences separating him him cheap designer *beep* him from the animals into a "no go zone," Cussons
Oberle did not have clearance to be standing in the the cheap Ralph Lauren the area past the public fence. Oberle stepped on a
peeceived by the chimps as their terrority when he neared neared cheap replica *beep* neared an electrified fence. Two male chimpanzees named Nikki and
reached underneath pulled him halfway under the fence by his his cheap polo shirts his foot. Oberle fought to not be pulled into the
At this point, the sanctuary instituted its lockdown procedure, Cussons Cussons [h3]cheap polo shirts[/h3] Cussons said. The institute believes the chimpanzees were able to |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
