>> 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.
Not sure what other choice there is.
>
>
>> 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).
Ooops, yes, should have been 'enabled TRUE'. Regardless, I rechecked this RQS
and it works fine.
>
> Maybe one rule:
>
>limit hosts {*} slots=$numproc would do.
This rqs would prevent superordinate jobs from running because you really want
to be able to schedule
up to 2*$num_proc jobs to each host (ignoring other reasonable constraints).
>
>-- 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
---------------------------------------------------------------------
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
