Am 05.04.2011 um 20:18 schrieb Stephen Dennis:
> <snip>
>>> 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
Stephen, can you please explain the two above rules to me? To me they read like:
All jobs running in queues low and high together and on all machines belonging
to @4_core should only use 4 slots in total - even if there are 100 machines in
the hostgroup.
>>> .....
>>> }
>>
>> 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).
Okay, then we have to multiply by two. But when there are two queues on each
host having exactly the number of num_proc defined as slots, we don't need the
RQS at all.
-- Reuti
>>
>> -- 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
