Possibly, though in this case (12 million slot dirs) that would imply that the client has 12 million tasks, which is unlikely because then the client would completely bog down because of the N^2 scheduling logic. It's more likely due to a failure to clean out slot dirs, and I suspect it's specific to Volpex.
I'll make the ncpus*100 change. -- David On 24-Oct-2013 11:26 AM, McLeod, John wrote:
An unbounded number of slot dirs. Would be caused by High Priority picking up a task, running it for a few minutes, discovering that that particular task was no longer in high priority, and picking up one that was now in high priority. Repeat until all tasks have run for a couple of minutes in high priority. (This should have been fixed by the recent change to EDF for the project rather than selecting the tasks that were tagged as high priority). The other way would be to have slots that cannot be cleaned out (but I thought that bug was fixed a while ago). On a different note, could we change the calculated maximum number of slots to cope with machines with more than 1000 CPUs? I know that machines like that are rare now. How about n_cpus * 100 for the number of slot directories allowed? _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
_______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
