> Am 14.08.2015 um 11:28 schrieb Tina Friedrich <tina.friedr...@diamond.ac.uk>: > > Hi Mark, > > > My experience with job subordination leads me to think that the >> subordination will only happen when: >> >> jobs of the two different groups are running on a single node >> -AND- >> a load value on that node has been execeeded >> (please let me know if this is wrong!). > > I don't think that's correct. Queue subordination can be set up so that any > job going into the predominant queue on a node will suspend all jobs > (actually, all queue instances and all jobs in them, naturally) in the > subordinate queue.
I assume he refers to "suspend_thresholds". Sure, it should be possible to set up a consumable and mimic the used slot count in the payed queue this way. (Although I just found that complexes can't be used as suspend_thresholds, while they are still working as load_thresholds.) -- Reuti > We rely on this mechanism quite heavily here :) > > Set up is (in queue conf of 'higher order' queue, called test-medium.q:) > > subordinate_list test-low.q=1 > > and that suspends test-low.q the moment a job goes into test-medium.q. And > the job in test-medium.q would always start, as it only sees free slots (all > slots on all nodes are in all queues, if that makes sense?) > >> My question is whether there is a mechanism for PayingCustomer jobs in >> the queue to kill Freebie jobs if they need those resources in order to >> move out of the queue and run. > > Well, I don't kill them, just suspend them; I have a scenario where certain > jobs/users need to be able to always run jobs now, and that's how we achieve > it. > >> For example, if there is an 8-slot server, with 3 Freebie jobs running, >> a PayingCustomer job that requires 6 cores will not start running if >> slots are shared between the queues. >> >> Even if slots were 'oversubscribed' (ie. both the PayingCustomer queue >> and the FreebieQ on the node were assigned 8 slots each), then the load >> average (or available memory, or some other load sensor) from Freebie >> jobs alone could still prevent PayingCustomer jobs from being assigned >> to that node. >> >> Any suggestions? >> >> Thanks, >> >> Mark >> _______________________________________________ >> users mailing list >> users@gridengine.org >> https://gridengine.org/mailman/listinfo/users >> >> > > > -- > Tina Friedrich, Computer Systems Administrator, Diamond Light Source Ltd > Diamond House, Harwell Science and Innovation Campus - 01235 77 8442 > > -- > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not use, > copy, retain, distribute or disclose the information in or attached to the > e-mail. > Any opinions expressed within this e-mail are those of the individual and not > necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot > guarantee that this e-mail or any attachments are free from viruses and we > cannot accept liability for any damage which you may sustain as a result of > software viruses which may be transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England and > Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > _______________________________________________ > users mailing list > users@gridengine.org > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
