> On Mar 7, 2018, at 5:52 AM, Benjamin Bannier <benjamin.bann...@mesosphere.io> 
> wrote:
> Hi,
>> Chatted with BenM offline on this. There's another option what both of us
>> agreed that it's probably better than any of the ones mentioned above.
>> The idea is to make `allocable` return the portion of the input resources
>> that are allocatable, and strip the unelectable portion.
>> For example:
>> 1) If the input resources are "cpus:0.001,gpus:1", the `allocatable` method
>> will return "gpus:1".
>> 2) If the input resources are "cpus:1,mem:1", the `allocatable` method will
>> return "cpus:1".
>> 3) If the input resources are "cpus:0.001,mem:1", the `allocatable` method
>> will return an empty Resources object.
>> Basically, the algorithm is like the following:
>> allocatable = input
>> foreach known resource type t: do
>> r = resources of type t from the input
>> if r is less than the min resource of type t; then
>>   allocatable -= r
>> fi
>> done
>> return allocatable
> I think that sounds like a faithful extension the current behavior to me 
> (removing too small resources from the offerable pool), but I feel we should 
> not just filter out any resource _kind_  below the minimum, but inside a kind 
> all _addable_ subresources,
>    allocatable : Resources = input
>      for (resource: Resource) in input:
>        if resource < min(resource.kind):
>          allocatable -= resource
>    return allocatable
> This would have the effect of clumping together each distinguishable resource 
> we care about instead of of accumulating say different disks which in sum are 
> potentially not that more interesting to frameworks (they would prefer more 
> of a particular disk than smaller pieces scattered across multiple disks).
> @alexr
>> If we are about to offer some of the resources from a particular agent, why
>> would we filter anything at all? I doubt we should be concerned about the
>> size of the offer representation travelling through the network. If
>> available resources are "cpus:0.001,gpus:1" and we want to allocate GPU,
>> what is the benefit of filtering CPU?
>> What about the following:
>> allocatable(R)
>> {
>> return true
>>   iff (there exists r in R for which size(r) > MIN(type(r)))
>> }
> I think this is less about communication overhead, but more a tool to help to 
> make sure that offered resources are actually useful to frameworks. 

I don't know whether there's a JIRA for this, but in the past we've proposed 
the idea of schedulers suppressing or filtering offers with a minimum resources 
specification, i.e. "don't bother me with offers that aren't at least X"


Reply via email to