Known to work with Condor version: 7.0
 
-Condor monitors the total virtual memory usage of jobs.  This includes both physical RAM and disk-based virtual memory allocated by the job.  While this provides a clear way to stop jobs from using more virtual memory than they should, what administrators often want is slightly more complicated: they want to limit the amount of physical RAM used by the job so that it doesn't cause performance problems for other jobs or tasks on the computer.  This is difficult to do in a general way, because Condor currently lacks a way to measure how much physical RAM the application actually needs verses how much of its memory could be swapped out to the disk without impacting performance.  (How much the application actually needs is known as the working set size.)
+Condor monitors the total virtual memory usage of jobs.  This includes both physical RAM and disk-based virtual memory allocated by the job.  Administrators often want to limit the amount of physical RAM used by the job so that it doesn't cause performance problems for other jobs or tasks on the computer.  This is difficult to do in a general way, because Condor currently lacks a way to measure how much physical RAM the application actually needs verses how much of its memory could be swapped out to the disk without impacting performance.  (How much the application actually needs is known as the working set size.)
 
 Example: Condor may see that the virtual memory size of a job is 1.5GB when there is only 1GB per slot on the 4 core system.  This could be a problem if jobs on the other slots need their full 1GB of expected memory.  However, it may be that there simply isn't demand for memory at the moment, so the operating system is letting this job keep more of its memory in physical RAM than it actually needs.  If something else comes along and demands more memory, the memory usage of this job might painlessly shift so that only 1.0GB is in physical RAM and the other 0.5GB is on disk, leaving the expected amount of RAM for other jobs without causing poor performance due to thrashing (actively needed data jumping back and forth between disk and RAM).
 
@@ -16,7 +16,6 @@
 {code}
 # Let a job use up to 90% of the memory allocated to its batch slot
 MEMORY_AVAILABLE_MB = (Memory*0.9)
-VIRTUAL_MEMORY_AVAILABLE_MB = (VirtualMemory*0.9)
 
 
 # The working set size is the amount of memory the job actually needs
@@ -40,8 +39,7 @@
 # memory size of the job is greater than the total virtual memory allocated
 # to this batch slot.  If either is true, then memory is exceeded.
 
-MEMORY_EXCEEDED = $(WORKING_SET_SIZE_MB) > $(MEMORY_AVAILABLE_MB) || \
-                  ImageSize/1024 > $(VIRTUAL_MEMORY_AVAILABLE_MB)
+MEMORY_EXCEEDED = $(WORKING_SET_SIZE_MB) > $(MEMORY_AVAILABLE_MB)
 
 PREEMPT = ($(PREEMPT)) || ($(MEMORY_EXCEEDED))
 
@@ -54,13 +52,11 @@
 {code}
 WANT_HOLD = ($(MEMORY_EXCEEDED))
 WANT_HOLD_REASON = \
-   ifThenElse( ImageSize/1024 > $(VIRTUAL_MEMORY_AVAILABLE_MB), \
-               "Your job used too much virtual memory.", \
    ifThenElse( ($(MEMORY_EXCEEDED)) && isUndefined(MemoryRequirementsMB), \
                "Your job used too much memory, as measured by ImageSize.  If virtual memory usage is not a reliable estimate of real memory requirements for your job, please add the attribute MemoryRequirementsMB to your job to override this check.", \
    ifThenElse( ($(MEMORY_EXCEEDED)), \
                "Your job used too much memory.", \
-               undefined ) ) )
+               undefined ) )
 
 {endcode}