[GE users] subordinate queues
reuti at staff.uni-marburg.de
Tue Nov 23 12:56:34 GMT 2010
Am 23.11.2010 um 13:34 schrieb sgenedharvey:
>> From: llikethat [mailto:bharanitn at yahoo.com]
>> Can someone please explain the use case of subordinate queues. in which
>> situation it plays a vital role. I read the documentation and it says it can be
>> used for high priority and low priority jobs. The subordinate queue uses the
>> slots as an attribute, how does this help.
> To tell the truth, I've been deploying SGE for around 10 yrs now, and I don't get it either.
> I write wrapper scripts around qsub anyway. To get all the other arguments that you want standard.
This can nowadays also be achieved by an JSV.
> So it's trivial to include job priority in the script. And when the time comes that all the execution hosts are used, and you need to preempt some job ... Just preempt the number of individual jobs you need. Why on earth preempt the whole queue?
> In 6.2u5, there's the new feature, 'slotwise preemption' which allows individual jobs of subordinate queues to be preempted. I just don't get why you would want to set things up this way, instead of preempting jobs by their jobid. It seems to me, that with slotwise preemption, you can finally come close to the same level of functionality.
I think this must be seen from the history: one big SMP machine with 128 cores. You want to suspend all jobs in the low priority queue when the high priority queue uses slots from a certain amount onwards. I.e. first you allow some kind of oversubscription, but at one point the low priority queue will be preempt completely. For one or two cores, there is no feasable range of values to chose from to start the preemption. But with 128 cores, you could say to allow 64 in the high priority queue and if it's getting more, the low priority queue will be preempt. This could also be seen in combination with a functional policy, where the high priority jobs won't get niced (i.e. reprioritized by the scheduler), but the low priority ones (as long as they are running).
To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].
More information about the gridengine-users