Github user mridulm commented on a diff in the pull request:

    https://github.com/apache/spark/pull/16603#discussion_r96714353
  
    --- Diff: core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java 
---
    @@ -144,8 +164,24 @@ public long acquireExecutionMemory(long required, 
MemoryConsumer consumer) {
           // spilling, avoid to have too many spilled files.
           if (got < required) {
             // Call spill() on other consumers to release memory
    +        // Sort the consumers according their memory usage. So we avoid 
spilling the same consumer
    +        // which is just spilled in last few times and re-spilling on it 
will produce many small
    +        // spill files.
    +        List<MemoryConsumer> sortedList = new 
ArrayList<>(consumers.size());
             for (MemoryConsumer c: consumers) {
               if (c != consumer && c.getUsed() > 0 && c.getMode() == mode) {
    +            sortedList.add(c);
    +          }
    +        }
    +        Collections.sort(sortedList, new ConsumerComparator());
    +        for (int listIndex = 0; listIndex < sortedList.size(); 
listIndex++) {
    +          MemoryConsumer c = sortedList.get(listIndex);
    +          // Try to only spill on the consumer which has the required size 
of memory.
    +          // As the consumers are sorted in descending order, if the next 
consumer doesn't have
    +          // the required memory, then we need to spill the current 
consumer at least.
    +          boolean doSpill = (listIndex + 1) == sortedList.size() ||
    +            sortedList.get(listIndex + 1).getUsed() < (required - got);
    +          if (doSpill) {
    --- End diff --
    
    Let me elaborate with the earlier example.
    Suppose you have consumers 1.5GB 1GB 500MB 2MB 1MB and we need 500 MB.
    
    In existing implementation, irrespective of the order of iteration, we will 
always end up freeing >= 500MB: for example (since iteration order is not 
known) - 2MB (released = 1.8M), 500 MB (released 490M), 1GB (released 0.99G) - 
the numbers are illustrative only.
    
    
    In the proposed implementation, we will ignore 1.5GB, 1GB - since 500MB >= 
required.
    When we get to 500MB, if the released = 490MB, we now end up in a situation 
where remaining blocks cannot satisfy the allocation request - and we end up 
freeing self.
    All the while when we actually do have blocks which could have been freed.
    
    
    
    Let me know if I am missing something.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org

Reply via email to