The last bit is an annoyance that we cannot get around.
The CPU scheduler would already have started a multi threaded application
that in conjunction with the tasks that are running takes more CPUs than
are available. This leads to frequent context switches which leads to
memory thrashing, and in the worst scenario disk thrashing.
jm7
Raistmer
<[email protected]
> To
Sent by: "David Anderson"
<boinc_alpha-boun <[email protected]>,
[email protected]. <[email protected]>
edu> cc
BOINC Developers Mailing List
<[email protected]>,
10/26/2009 02:27 [email protected],
PM [email protected]
Subject
Re: [boinc_alpha] [boinc_dev] CPUs
Idle BM v6.10.16 Vista64
> We may have to set a time limit on how long to wait for a checkpoint.
> Some
> applications still never checkpoint. At least one application does not
> checkpoint, and loses hours of work when it is left in memory when
> suspended.
If some limit will be set and then such app will be preempted when limit
reached, then it will lose hours of work anyway.
So question is - why some limit to wait then needed? App that can't do
checkpoint just should not be suspended.
BOINC should wait while it finishes and then not run such tasks long enough
to compensate excessive usage of resources by such app.
BTW, such kind of apps will eventually be discarded - not too many
participants wanna lose hours of works just on PC reboot or other event
external to BOINC. That is, with BOINC scheduling or w/o it such app pretty
unstable one. BOINC should just avoid making it more unstable :)
_______________________________________________
boinc_alpha mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
