[GE users] Please Review: Non-Multiplied Consumable Requests for Parallel Jobs

Bradford, Matthew matthew.bradford at EDS.COM
Thu Sep 25 13:33:31 BST 2008


 

>-----Original Message-----
>From: Andy Schwierskott [mailto:andy.schwierskott at sun.com] 
>Sent: 25 September 2008 12:35
>To: users at gridengine.sunsource.net
>Subject: Re: [GE users] Please Review: Non-Multiplied 
>Consumable Requests for Parallel Jobs
>
>Reuti,
>
>> > as Andy already mentioned in our Release Plan we intend change the 
>> > multiplication by slots behavior for consumable requests with PE 
>> > jobs. The spec how we suggest to target this issue is 
>attached. Any 
>> > feedback or comments are appreciated.
>>
>> this is great and sounds reasonable. It will cover a few RFEs in 
>> Issuzilla at once.
>
>One RFE is not covered: exclusive node allocation. A host can 
>accept multiple jobs to run, but a job requesting a host 
>exclusively cannot run when there are other jobs already 
>running on that host. As soon as a exclusive job is running 
>the host would not accept any other jobs.
>
>We've been discussing it, but time will be likely too limited 
>to implement this for Urubu. The rule would be as follows:
>
>E  = exlusive job
>NE = non exclusive job
>
>job  host status     action
>------------------------------------
>NE   empty           schedule
>NE   NE running      schedule
>NE   E running       do not schedule
>E    empty           schedule
>E    NE running      do not schedule
>E    E running       do not schedule
>
>To say it in other words:
>
>  if (NE)
>     if (E running)
>        do not schedule
>     else
>        schedule
>  else
>     if (empty)
>        schedule
>     else
>        do not schedule

Andy,

The ability to request exclusive nodes would be really useful for us.
One thing, we use the ACCT_RESERVED_USAGE and SHARETREE_RESERVED_USAGE
so that users get charged for the number of slots that they are using up
(NSlots x WallTime). It would be good if requesting an exclusive job
would mean that a user gets charged for using up all the slots in the
containing queue, as we wouldn't want a user to request a single slot on
a 16 core machine, but with exclusive access and not be charged for it.

Cheers,

Mat
>
>In addition it should be possible to mark a host to accept 
>exclusive jobs only to avoid to setup a special queue for those hosts.
>
>In principle I think it should not be limited to one exclusive 
>job but up to N jobs. Is there a realistic use case for it for 
>that scenario?
>
>> One small question: there was somewhere on the mailing list 
>> mentioning, that his software needs one license per host, independed 
>> from the number of processes/jobs running there (host-locked 
>floating 
>> license). As far as I understand the complex attached as HOST 
>> consumable right now, it's per job on a node. So to cover 
>his request 
>> we would need another type like HOSTLOCKED / HOSTONCE or so? 
>The total 
>> amount could be specified by setting it in global then.
>
>Do you think you can find the RFE in issuezilla?
>
>Well, if you manage this license as follows:
>
>global_host:   complex_values host-locked-float-lic=1
><hosts>:       complex_values host-locked-float-lic=1
>
>at most 1 job could run in the whole cluster requesting the 
>host-locked-float-lic license. Or di I misunderstand the use case?
>
>Andy
>
>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list