[GE users] limits on real memory

reuti reuti at staff.uni-marburg.de
Fri Nov 20 16:02:57 GMT 2009


Am 18.11.2009 um 15:55 schrieb goncalo:

>>> But, in my opinion, this should not work like that... I should be  
>>> able
>>> to discriminate between the two. For example, there are applications
>>> which use 2GB of RAM memory and also write to SWAP some stuff which
>>> they
>>>
>> are you really speaking of the swap space or any scratch space on the
>> disk? I'm not aware, that an application (which gets the illusion of
>> a contiguous block of memory) can access the swap space directly.
>> This is usually the kernel's duty to move pages from memory to swap
>> when they are unused and move them back again.
>>
>
> I didn't express myself properly, sorry. I meant that a significant
> number of the pages used by an application during its startup phase  
> may
> only be used for initialization and then never used again. The system
> can send to swap those pages and free the memory for other  
> applications
> or even for the disk cache. In this case, I'm not interested in the
> total virtual memory of the aplication

When I understand you in the right way, you would allow during the  
initialitaion phase a higher limit, and later on this should decline.  
This is not possible with h_vmem.

Maybe you can use virtual_free instead of h_vmem. As this limit is  
not enforced, you can request just the amount the application will  
need during its final execution. To compensate for the higher  
consumption at the beginning, you could define some adjustments in  
the scheduler configuration (see entries "job_load_adjustments" and  
"load_adjustment_decay_time").

If you like, you can also make virtual_free consumable and attach an  
initial value to each exechost. Just note, that the corrected load is  
subtracting from the real load, not the computed complex.

-- Reuti

------------------------------------------------------
http://gridengine.sunsource.net/ds/viewMessage.do?dsForumId=38&dsMessageId=228249

To unsubscribe from this discussion, e-mail: [users-unsubscribe at gridengine.sunsource.net].



More information about the gridengine-users mailing list