On 09/03/12 20:11, Reuti wrote: > Am 09.03.2012 um 18:34 schrieb Robert Hutton: >> Currently, there is only one queue that all jobs get scheduled in, >> called longrun.q. But this means that very short jobs sometimes have to >> wait for very long jobs to finish before they can get any slots in that >> queue. What I'd like to do is have a second queue, shortrun.q, in which >> any short jobs get run, with slotwise preemption set up so that they can >> quickly run and then let the longer jobs continue. >> >> I set up this very thing, with a h_rt limit of 2 hours on the >> shortrun.q, but it had unexpected consequences when there were no long >> running jobs filling longrun.q and a user submitted a lot of very >> short-running jobs: longrun.q and shortrun.q both immediately filled >> with short jobs, with the jobs in longrun.q immediately preempted by >> those in shortrun.q. >> >> I suppose my question is: is there any way to prevent the short running >> jobs from entering longrun.q, or do I have to tell my users to use "-q >> shortrun.q" when they want to schedule jobs with h_rt less than two hours? > > Instead of requesting a queue, it would be more flexible to request a boolean > complex, which is attached to the shortrun.q.
I set up a boolean complex: #name shortcut type relop requestable consumable default urgency #---------------------------------------------------------------------- priority prio BOOL == YES NO 0 0 And attached it to my shortrun.q: complex_values virtual_free=12G,h_vmem=13G,priority=TRUE But now I have to specify -l prio=false on all qsub commands that I don't want to go into shortrun.q. If I don't specify -l prio=false, then the behaviour is the same as before, that is, the jobs can go into either longrun.q or shortrun.q. Is there a way to attach prio=false by default to any job that doesn't specify a value for it? I note this from the sge_complex(5) man page: > default > Meaningful only for consumable complex attributes (see consumable > parameter above). I've tried requestable FORCED, but this doesn't seem to change the behaviour. I suspect that I'm making a pretty obvious mistake here... ;) Thanks again, Rob -- Robert Hutton Senior Systems and Database Administrator Centre for Genomics and Global Health <http://cggh.org> The Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Tel: +44 (0)1865 287721 _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
