manirajv06 commented on PR #945:
URL: https://github.com/apache/yunikorn-core/pull/945#issuecomment-2293277387

   > I am wondering why we never filter the nodes to start with: if the 
allocation asks for a resource type not registered by the node. Or if the node 
is too small for the allocation. We should remove the node if the allocation 
does not fit the capacity to start with. We do some filtering in the 
`initWorkingState()` call but we do not check that. If we have that check there 
will be no impact of the change from `FitiIMaxUndef()` to `FitIn()`.
   > 
   
   Reason for not doing the check in `initWorkingState` method is to consider 
that node for further steps and to avoid elimination then and there. Though 
fitIn check fails bit later in `calculateVictimsByNode()`, returning empty 
allocations list for that specific node makes it to pass through further steps. 
One important step among them is to running normal predicate checks to ensure 
node doesn't have any predicate failures. So, moving the check bit higher up in 
the hierarchy would eliminate the node which is something we don't want to do.
   
   BTW, only allocations (victims) sorting between those two methods, which we 
won't happen anyway for this node as there are no allocations (victims). Hence, 
there is not much difference form performance perspective.
   
   Since FitIn() check happens in `calculateVictimsByNode()` happens in the 
beginning stage as discussed above, doing the same again should not have any 
impact.
   
   > BTW: we have an optimisation around the start of 
`calculateVictimsByNode()` we need to make. Creating the copy of the queue 
snapshot (Line 216) should not happen until after we checked the node should be 
looked at (Line 223) Currently we duplicate objects and then check. Which drops 
all the work and just costs CPU, memory and GC if we do not consider the node.
   
   Taken care.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to