[DRMAA-WG] DRMAAv2 C binding - "DRMAA2_TRUE64"?

Daniel Gruber dgruber at univa.com
Thu May 24 04:54:56 EDT 2012


Peter,

We are correct with DRMAA2_DATA_SEG_SIZE. We were always aligned on the 
DRM capabilities and as well on the setrlimit() call semantics.  The data segment 
semantic covers heap growing:

man 2 setrlimit
       RLIMIT_DATA
              The  maximum size of the process's data segment (initialized data, uninitialized data, and heap).  This limit affects calls to brk(2) and sbrk(2), which fail with the error ENOMEM
              upon encountering the soft limit of this resource.

And the POSIX description:

man 3p setrlimit

       RLIMIT_DATA
              This is the maximum size of a process' data segment, in bytes. If this limit is exceeded, the malloc() function shall fail with errno set to [ENOMEM].

This is handled in Grid Engine in the same manner.

Daniel

Am 24.05.2012 um 10:08 schrieb Peter Tröger:

>> 
>> Any comments, esp. the DRMAA2_DATA_SEG_SIZE issue?
> 
> The current list of supported resource restrictions did not came from application needs in the first place, but from what is reasonably supported in the majority of DRM / OS systems. Are heap restrictions widely supported  ?
> 
> Another point is that the list was agreed as part of the root specification, so we need to have extremely good arguments to remove or add stuff. Fixing naming issues ("TRUE64") is one thing, but semantic changes of the API are another one.
> 
>> And if we need to talk about them, when is the next DRMAA call?? (I
>> attended a few of the DRMAA phone conferences when DanT was
>> representing Sun Grid Engine, and my understanding is that we now use
>> Skype as Oracle is not sponsoring the 1800 phone conferences anymore.)
> 
> Phone conferences are suspended until we have a need for them. This will most likely be the case when the public comment period for the C binding is over. You will get an announcement on the mailing list.
> 
> Best regards,
> Peter.
> 
> 
> 
>> 
>> Rayson
>> 
>> =================================
>> Open Grid Scheduler / Grid Engine
>> http://gridscheduler.sourceforge.net/
>> 
>> Scalable Grid Engine Support Program
>> http://www.scalablelogic.com/
>> 
>> 
>> 
>> On Fri, May 11, 2012 at 3:38 PM, Rayson Ho <rayrayson at gmail.com> wrote:
>>> I have three more issues:
>>> 
>>> 1) Mac OS and Mac OS X are 2 different platforms. Mac OS is the much
>>> older OS that is not supported anymore, and Mac OS X is the one that
>>> is based on the Darwin & Unix kernel.
>>> 
>>> May be we should change:
>>> 
>>> DRMAA2_MACOS -> DRMAA2_MACOSX
>>> 
>>> Even Apple sw_vers tool prints Mac OS X as the product name:
>>> 
>>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/sw_vers.1.html
>>> 
>>> 
>>> 2) We have x86 and the 64-bit version x64, and we also have PPC &
>>> PPC64, SPARC & SPARC64.
>>> 
>>> But where is the 64-bit version of ARM (DRMAA2_ARM)?
>>> 
>>> We (the Open Grid Scheduler project) added support for ARM since Open
>>> Grid Scheduler/Grid Engine 2011.11, and we think ARM will be used by
>>> lots more sites when 64-bit ARM hits the market - note that the 64-bit
>>> ARM architecture was announced last year.
>>> 
>>> Also, China developed a series of 64-bit MIPS processors called
>>> Loongson, and 64-bit MIPS is manufactured by other companies as well -
>>> to keep the architecture selection consistent, shouldn't we also have
>>> DRMAA2_MIPS & DRMAA2_MIPS64?
>>> 
>>> 
>>> 3) DRMAA2_DATA_SEG_SIZE - the data segment does not change when a
>>> process runs, as the data segment contains global & static (and common
>>> in Fortran) variables. I can't think of anyone who explicitly wanted
>>> to limit the size of the data segment.
>>> 
>>> What we do need is a limit for the Heap (sbrk(), malloc(), C++'s new,
>>> etc) - this is the memory we care about.
>>> 
>>> IMO, we should change the name to DRMAA2_HEAP_SIZE
>>> 
>>> Rayson
>>> 
>>> =================================
>>> Open Grid Scheduler / Grid Engine
>>> http://gridscheduler.sourceforge.net/
>>> 
>>> Scalable Grid Engine Support Program
>>> http://www.scalablelogic.com/
>>> 
>>> 
>>>> 
>>>> I will post the link if it is available. Thanks for your review !
>>>> 
>>>> Best regards,
>>>> Peter.
>>>> 
>>>> 
>>>>> 
>>>>> Rayson
>>>>> 
>>>>> =================================
>>>>> Open Grid Scheduler / Grid Engine
>>>>> http://gridscheduler.sourceforge.net/
>>>>> 
>>>>> Scalable Grid Engine Support Program
>>>>> http://www.scalablelogic.com/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Apr 17, 2012 at 5:16 AM, Peter Tröger<peter at troeger.eu>  wrote:
>>>>>> 
>>>>>> Dear all,
>>>>>> 
>>>>>> the DRMAAv2 C binding is now in final draft state. Attached you can find
>>>>>> the annotated and the official version of the specification, as well as the
>>>>>> raw header file.
>>>>>> 
>>>>>> Please provide your final comments on the mailing list until *April 22nd*
>>>>>> (this Sunday). In case, we will set up a conf call for last discussions.
>>>>>> Otherwise, the document will enter the OGF document process on next Monday.
>>>>>> 
>>>>>> Thanks and best regards,
>>>>>> Peter.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> drmaa-wg mailing list
>>>>>> drmaa-wg at ogf.org
>>>>>> https://www.ogf.org/mailman/listinfo/drmaa-wg
> 
> --
>  drmaa-wg mailing list
>  drmaa-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/drmaa-wg



More information about the drmaa-wg mailing list