Am 05.04.2011 um 19:25 schrieb Stephen Dennis:
> Hi Vic
>
> What you are interested in doing is possible and is one of the main purposes
> of the slotwise subordination.
>
> There are some limitations related to defects in the implementation:
> 1. SGE 6.2u5 has a defect which causes jobs to remain trapped in suspension.
> (fix for this is in all the source distributions, or upgrade to Univa
> Grid Engine v8 later this month)
> 2. SGE 6.2u5 can 'black hole' jobs...that is that jobs can be run in a slot
> where they will immediately be suspended
> (do not use qmod -sj or -rj on jobs)
> 3. SGE 6.2u5 unpredictable behaviour subordinating parallel (-pe) jobs
> (do not use a pe_list)
> 4. SGE 6.2u5 also has scalability limitations
> (keep configuration very simple)
>
> Also, subordination does not have a built in slots limitations...but RQS can
> be used.
>
> Even with those limitations are there are workable configurations.
>
> 1. Keep it very simple with a high queue and a low queue.
> 2. Remove the pe_list from both those queues.
The question is, whether the OP needs PEs.
> 3. Create a host group for each class of machines by core count (eg.
> @4_core, @8_core, ....)
> 4. Create a host group for each of your working groups (eg. @bio, @physics,
> ...)
>
> The high queue will have a subordinate list like this...
> subordinate_list NONE,[@8_core=slots=8(low:0:sr)],
> [@4_core=slots=4(low:0:sr)] ....
> Create an rqs to keep slot usage in bounds.
> {
> name slotcap
> description slot count associated with host
> enabled FALSE
> limit queues low,high hosts @4_core to slots=4
> limit queues low,high hosts @8_core to slots=8
> .....
> }
AFAICS this is a restriction that all jobs in queues low plus high in the
complete hostgroup @8_core can only use 8 slots in total (if it will be
enabled).
Maybe one rule:
limit hosts {*} slots=$numproc
would do.
-- Reuti
> Users of the low queue can just submit with
> qsub -q low .....
>
> But users of the high queue need to have some restriction to their 'own'
> machines, for example, something like
> qsub -q high@@bio ....
>
> Thanks
> Stephen
>
> ############################################################################
> # Stephen Dennis : Senior Sales Engineer
> # Univa Corporation: univa.com/products/grid-engine.php
> # [email protected] : 310 310 0738 : skype stephendennis.com
> ############################################################################
>
> ________________________________________
> From: [email protected] [[email protected]] On Behalf
> Of Vic [[email protected]]
> Sent: Tuesday, April 05, 2011 4:23 AM
> To: [email protected]
> Subject: [gridengine users] Slotwise preemption - is this possible?
>
> Hi All.
>
> I've just started reading up on slotwise preemption - it looks almost
> exactly like what I need. But I'd like to do things slightly differently
> :-)
>
> What I'm after is for the subordination list to be on a per-hostgroup
> basis, not a per-queue one. In other words, one queue is subordinate to
> the other on one set of hosts, but the opposite subordination applies on
> the other hosts.
>
> What I'm trying to achieve is to merge two working groups into one grid.
> Group A has bought its hosts, and wants priority on those, whereas group B
> has a different set of hosts, and wants priority on them. But rather than
> run two separate grids, I want to be able to allocate jobs from either
> group to any host - but with the proviso that each group can reclaim its
> own machines if it needs to.
>
> Is this possible with preemtpion? Is there a simpler way to achieve my
> goals? Which FM should I go and RT? I'm a bit new to GridEngine, so I
> might well have missed the obvious here.
>
> Many thanks,
>
> Vic.
>
>
>
> _______________________________________________
> users mailing list
> [email protected]
> https://gridengine.org/mailman/listinfo/users
>
>
> ---------------------------------------------------------------------
>
>
> Notice from Univa Postmaster:
>
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies of
> the original message. This message has been content scanned by the Univa Mail
> system.
>
>
>
> ---------------------------------------------------------------------
>
>
> _______________________________________________
> users mailing list
> [email protected]
> https://gridengine.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
