Feature request: limit processor affinity (smp machines)

Message boards : BOINC client : Feature request: limit processor affinity (smp machines)
Message board moderation

To post messages, you must log in.

AuthorMessage
tgm

Send message
Joined: 8 Sep 05
Posts: 4
Message 1450 - Posted: 2 Dec 2005, 12:11:08 UTC

I am running two projects; seti@home that uses a modest amount of memory, and World Community grid that uses a large portion of memory. What I would like to be able to do is to set a processor affinity limit to a particular project in order to limit the amount of total memory that boinc is consuming. For example; set seti@home to only use processor #1 and WCG to processor #2. This would drastically improve swapping and memory consumption.
ID: 1450 · Report as offensive
Metod, S56RKO

Send message
Joined: 9 Sep 05
Posts: 128
Slovenia
Message 1514 - Posted: 4 Dec 2005, 11:01:32 UTC - in response to Message 1450.  
Last modified: 4 Dec 2005, 11:02:49 UTC

I am running two projects; seti@home that uses a modest amount of memory, and World Community grid that uses a large portion of memory. What I would like to be able to do is to set a processor affinity limit to a particular project in order to limit the amount of total memory that boinc is consuming. For example; set seti@home to only use processor #1 and WCG to processor #2. This would drastically improve swapping and memory consumption.


On a typical SMP mchine, where you also have shared-memory design, you won't really gain much from that. The only thing you will gain by 'locing' processes to particular CPUs is that when OS scheduller moves one process over to another processor, it won't have to flush and re-fill the L2 nd L1 caches.

Nothing there about memory consumption and swapping (as every single byte of information is identically accessible by both (all) processors).

Things are different if you start to talk about non-SMP multi-processor beasts (such as some clustered machines or huge mainframes, etc.). But then, there are special process schedullers run which really take care about CPU affinity on those beasts.
Metod ...
ID: 1514 · Report as offensive
ohiomike
Avatar

Send message
Joined: 26 Dec 06
Posts: 26
United States
Message 14202 - Posted: 4 Dec 2007, 12:23:45 UTC - in response to Message 1514.  

I am running two projects; seti@home that uses a modest amount of memory, and World Community grid that uses a large portion of memory. What I would like to be able to do is to set a processor affinity limit to a particular project in order to limit the amount of total memory that boinc is consuming. For example; set seti@home to only use processor #1 and WCG to processor #2. This would drastically improve swapping and memory consumption.


On a typical SMP mchine, where you also have shared-memory design, you won't really gain much from that. The only thing you will gain by 'locing' processes to particular CPUs is that when OS scheduller moves one process over to another processor, it won't have to flush and re-fill the L2 nd L1 caches.

Nothing there about memory consumption and swapping (as every single byte of information is identically accessible by both (all) processors).

Things are different if you start to talk about non-SMP multi-processor beasts (such as some clustered machines or huge mainframes, etc.). But then, there are special process schedullers run which really take care about CPU affinity on those beasts.

The flush/re-load is costly in terms of time! With more an more multiple core machines out there, I think this is something that needs to be looked into.


ID: 14202 · Report as offensive
Nicolas

Send message
Joined: 19 Jan 07
Posts: 1179
Argentina
Message 14206 - Posted: 4 Dec 2007, 17:23:41 UTC - in response to Message 1450.  

It was suggested many times, but tests showed the performance improvement wasn't worth the effort of making the client set affinity on the science apps.

ID: 14206 · Report as offensive

Message boards : BOINC client : Feature request: limit processor affinity (smp machines)

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.