pbacsko commented on a change in pull request #384:
URL: 
https://github.com/apache/incubator-yunikorn-core/pull/384#discussion_r834340153



##########
File path: pkg/scheduler/objects/application.go
##########
@@ -1264,6 +1264,9 @@ func (sa *Application) AddAllocation(info *Allocation) {
 // Add the Allocation to the application
 // No locking must be called while holding the lock
 func (sa *Application) addAllocationInternal(info *Allocation) {

Review comment:
       @chungen0126 
   
   Today I had a discussion and code-checking session with @wilfred-s and our 
conclusion is that this method is not the right place for this check.
   
   We think that you should put this into `Queue.TryAllocate()` like that:
   
   ```
   func (sq *Queue) TryAllocate(iterator func() NodeIterator) *Allocation {
           if !sq.CanRun() {   // maxApplications reached
               return
           }
        if sq.IsLeafQueue() {
                // get the headroom
                headRoom := sq.getHeadRoom()
                // process the apps (filters out app without pending requests)
   ...
   ```
   If you can't run at any level, you just leave and return immediately. That 
way you won't calculate allocations and update data structures.
   
   However, this has an effect on `CanRun()` because in `TryAllocate()` we're 
walking down the hierarchy from "root", rather than checking from a particular 
leaf queue.
   
   So I think we need something like:
   ```
   func (sq *Queue) CanRun() bool {
        sq.RLock()
        defer sq.RUnlock()
   
        if sq.maxRunningApps == 0 {
                return true
        }
        
        return sq.runningApps < sq.maxRunningApps
   }
   ```
   
   So we don't need to check the parent all the way back to "root", because at 
any given level, we already know that. Eg if we're at "root.users.dev", we 
already know that "root.users" can accept new applications, because we're 
updating the counters constantly.
   
   I hope this makes sense.




-- 
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