[torquedev] Resource attributes expected functionality using qsub

John Rosenquist jrosenquist at adaptivecomputing.com
Tue Mar 22 14:47:44 MDT 2011


Oops, html should now be turned off.


Thank you for the feedback.

  From what I can tell there are 7 possible entry points for job data.
1.) environment
2.) command line
3.) code logic
4.) static defaults in the code
5.) config file
6.) script
7.) pbs_filter

According to what I'm reading in the code, this is the order of priority
in which the arguments are processed, with higher priority taking
precedence over lower.

3 - code logic (This will take an existing value and modify it. For
example, expanding a hostname to a FQDN)
2 - command line
7 - pbs_filter
6 - script
5 - config file
1 - environment
4 - static default

Does this also match the community expectation?

In terms of argument functionality, we've been talking about that and
were thinking about modifications along the following lines.

If an identical flag is passed along the commandline in multiple
locations, the job would be rejected. (Along the lines of the direct
feedback)
After that, the list above would be followed, with pbs_filter having the
ability to reject the job as well.

i.e. The following would generate errors.
1.) qsub -m fjr,jur,hud -m juk,kil,hud script.sh
2.) qsub -l nodes=3,mem=2Gb -l nodes=2 script.sh

1 would be rejected for two -m entries.
2 would be rejected for duplicate nodes entries.

But the follow would not be rejected.
qsub -l nodes=2 -l mem=2GB script.sh
As each entry in the resource set is unique.

As part of the debugging output the code would print out the list of job
attributes and their sources before the pbs_submit call.

Based on the current usage in the community, how does this sound?



On 03/18/2011 05:18 PM, John Rosenquist wrote:
> I recently started working at adaptive computing on the team that works
> on Torque.
>
> I have been looking at qsub and had a question. (Short explanation of
> the question first)
>
> Use the -l flag on the command line you can submit the same resource
> name with different values.
> i.e.
> 1.) qsub -l nodes=2:ppn=3,mem=3MB {bunch of other flags} -l
> mem=2MB,walltime=2:00 script.sh
> 2.) qsub -l nodes=2:ppn=3,mem=4MB,nodes=3:ppn=1,mem=5MB script.sh
> 3.) qsub -l nodes=1:ppn=6 script.sh
>
> script.sh can also have a -l flag with resource information
> #PBS -l nodes=4:ppn=4,mem=6MB,walltime=1:00
>
> Currently, from what I understand of the code, the qsub parses all of
> the command line options and adds all of them to the resource linked
> list. Then it add and resources found in any additional locations
> (including the script) but only if they don't already exist. It then
> ships all the resources over to the server (whether there is duplication
> or not). On the server side, when it parses the resources, everything
> but the last resource value is overwritten.
> Using the line from the script above for both qsub commands, the lines
> above end up as the following on the server after being parsed.
>
> 1.) -l notes=2:ppn=3,mem=2MB,walltime=2:00
> 2.) -l nodes=3:ppn=1,mem=5MB,walltime=1:00
> 3.) -l nodes=1:ppn=6,mem=6MB,walltime=1:00
>
> The question is, if someone used this mixture of locations to add
> resource information (and/or had multiple duplicate -l flags on the
> command line), what it the current expected functionality?
>
>
> Thanks.
> --
> John Rosenquist | Torque Developer
> Direct Line: 801.717.3--- | Fax: 801.717.3738
> 1656 S. East Bay Blvd. Suite #300 | Provo, Utah 84601 | USA
> Adaptive Computing, Ent.
> File:Sig.png <File:Sig.png>
>
>
>
> _______________________________________________
> torquedev mailing list
> torquedev at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torquedev

-- 
John Rosenquist | Torque Developer
Direct Line: 801.717.3--- | Fax: 801.717.3738
1656 S. East Bay Blvd. Suite #300 | Provo, Utah 84601 | USA
Adaptive Computing, Ent.


More information about the torquedev mailing list