Opened 16 years ago
Closed 15 years ago
#843 closed Enhancement (wontfix)
Interface for project pairing ability on multicore CPUs
Reported by: | Raistmer | Owned by: | davea |
---|---|---|---|
Priority: | Major | Milestone: | Undetermined |
Component: | Client - Scheduler Policy | Version: | |
Keywords: | project pairing | Cc: |
Description
Very needed feature for tasks scheduling still missing. There are many cases when science app from one project works faster/slower in presence of science app from particular another project.
For example: 1) more CPU cache intensive app will work better with app from another project that requires less cache amount than with another copies of itself. 2) More HDD intensive (database oriented) app will work better being paired with CPU intensive app and not with another copy of itself. 3) running few clones of same app can lead to excessive cache line evictions due to memory aliasing. and so on.
So, it would be nice to have some mechanism that will allow user to describe projects relations for BOINC scheduler: what science app BOINC should run together with what app from another project on multicore CPU.
Currently available "Resource share" mechanism is not enough for this aim.
Change History (6)
comment:1 Changed 16 years ago by
Owner: | changed from Bruce Allen to davea |
---|
comment:2 Changed 16 years ago by
Component: | Server - Scheduler → Client - Scheduler Policy |
---|
This is a client feature.
comment:3 Changed 16 years ago by
I think this should be supported, even if the client source code needs to be modified to change a project relation. (Currently there is no internal framework to support something like this)
comment:4 Changed 15 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This would be more trouble than it's worth.
comment:5 Changed 15 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Version: | 6.4.5 |
Strongly disagree. There is at least one SETI app (opt AP ) that exhibits performance degradation when 2 instances of it running simultaneously. Avoiding such situation (there are 2 SETI apps available, SETI MB and SETI AP ) will improve overall project performance. BOINC client scheduling policy should account for this even if there will be no user-adjustable settings.
comment:6 Changed 15 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Do you understand the cause?
It's not just about not running the same app twice. It's about exactly how much CPU cache they use and having complex rules of which apps "behave nice" with which other apps.
If you run two AP instances, it slows down. But it also slows down if you use AP and another app with similarly-big cache usage. And if you run two little-RAM apps at the same time there is no slow down. It's way more complex than you make it seem it is.
Reassigning to David.