You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 10, 2021. It is now read-only.
Various schedulers have different ways of specifying resource limits for jobs (e.g. memory, CPU, etc.). It would be nice to explore making these first class citizens in dask-drmaa. As DRMAA doesn't really have a way to specify this itself, it would amount to detecting the DRMAA implementation used and passing along the right flags to the nativeSpecification parameter of the JobTemplate. That said, we have already had some success with this strategy w.r.t. log files as demonstrated by PR ( #56 ). So should be pretty reasonable to extend the strategy to this case as well.
Various schedulers have different ways of specifying resource limits for jobs (e.g. memory, CPU, etc.). It would be nice to explore making these first class citizens in dask-drmaa. As DRMAA doesn't really have a way to specify this itself, it would amount to detecting the DRMAA implementation used and passing along the right flags to the
nativeSpecification
parameter of theJobTemplate
. That said, we have already had some success with this strategy w.r.t. log files as demonstrated by PR ( #56 ). So should be pretty reasonable to extend the strategy to this case as well.ref: https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_admin/resource_usage_limits_supported.html
ref: https://slurm.schedmd.com/sbatch.html
ref: http://gridscheduler.sourceforge.net/htmlman/htmlman5/queue_conf.html
ref: http://apps.man.poznan.pl/trac/slurm-drmaa#Nativespecification
The text was updated successfully, but these errors were encountered: