[GE users] h_vmem as consumable and stack size

reuti reuti at staff.uni-marburg.de
Tue Mar 3 19:06:52 GMT 2009


Hi,

Am 03.03.2009 um 13:41 schrieb andy:

> I can provide some more insight :-)
>
> A user running Gaussian was running into a similar problem:  
> Gaussian did not

is it still happening with Gaussian? We are also using this software  
and I just can't reproduce it right now with any version - or there  
is a setting I simply overlooked. Although I faced this error also in  
the past for sure.

Could it be an issue of the used kernel version or its configuration?

-- Reuti


> behave properly when *_stack could not be set > *_vmem. We provided  
> the user
> a shepherd binary where the last four lines of the code are *not*  
> executed:
>
> source/daemons/shepherd/setrlimits.c
> [snip]
>    /*
>     * s_vmem > h_vmem
>     * data segment limit > vmem limit
>     * stack segment limit > vmem limit
>     * causes problems that are difficult to find
>     * we try to prevent these problems silently
>     */
>    if (s_vmem > h_vmem) {
>       s_vmem = h_vmem;
>    }
>    s_data = RL_MIN(s_data, s_vmem);
>    s_stack = RL_MIN(s_stack, s_vmem);
>    h_data = RL_MIN(h_data, h_vmem);
>    h_stack = RL_MIN(h_stack, h_vmem);
> [snap]
>
> The user confirmed that Gaussian is working properly with such a  
> shepherd
> binary.
>
> This evaluation was done a little late for SGE 6.2u2 (comming out  
> these
> days), so we plan to integrate this change in SGE 6.2u3 (planned  
> for late
> May) and possibly (not yet confirmed) for the next SGE 6.1 patch  
> (no date
> planned).
>
> Frankly I don't think it's a SGE bug, but an application bug of  
> Gaussian
> (and Matlab which was referenced in this thread). However if it  
> helps to
> solve our user's problem I think we scan fix this in SGE than  
> waiting until
> the Gaussian and Matlab vendors are able or willing to fix this in  
> their
> software.
>
> I would like to know of anyone who is experiencing this problem had  
> raised a
> ticket with the Gaussian/Matlab vendors or if there is possibly  
> already an
> answer available?
>
> Anyhone who can not wait for the next SGE patches and who need to  
> use limits
> other than "infinity" can compile a shepherd binary where the  
> affected four
> lines of code are commented out. If you don't want to use CVS, tar.gz
> snapshots of many SGE versions and patches are available under
>
>    http://gridengine.sunsource.net/servlets/ProjectDocumentList
>
>
> Andy
>
>
> On Tue, 3 Mar 2009, reuti wrote:
>
>> Hi Sabine,
>>
>> Am 03.03.2009 um 10:12 schrieb s_kreidl:
>>
>>> Ok, thanks Reuti.
>>>
>>> Is there a special reason, why you set the stack and data size
>>> limits in conjunction with the virtual memory size?
>>> And do you plan on leaving the procedure like that in later
>>> versions of the SGE?
>>
>> I don't have more insights about it than the comments in the source:
>>
>>     /*
>>      * s_vmem > h_vmem
>>      * data segment limit > vmem limit
>>      * stack segment limit > vmem limit
>>      * causes problems that are difficult to find
>>      * we try to prevent these problems silently
>>      */
>>
>> And hence the limit is for h_data and h_stack is set in addition to
>> h_vmem. This ist still the actual behavior in the latest CVS.
>>
>> -- Reuti
>>
>>
>>> Thanks,
>>> Sabine
>>>
>>> ------------------------------------------------------
>>> http://gridengine.sunsource.net/ds/viewMessage.do?
>>> dsForumId=38&dsMessageId=119456
>>>
>>> To unsubscribe from this discussion, e-mail: [users-
>>> unsubscribe at gridengine.sunsource.net].
>>
>> ------------------------------------------------------
>> http://gridengine.sunsource.net/ds/viewMessage.do? 
>> dsForumId=38&dsMessageId=119506
>>
>> To unsubscribe from this discussion, e-mail: [users- 
>> unsubscribe at gridengine.sunsource.net].
>>
>
> ------------------------------------------------------
> http://gridengine.sunsource.net/ds/viewMessage.do? 
> dsForumId=38&dsMessageId=119559
>
> To unsubscribe from this discussion, e-mail: [users- 
> unsubscribe at gridengine.sunsource.net].

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

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



More information about the gridengine-users mailing list