Thanks Daniel & Roger. I think both are good suggestions. And yes, that's the first impression I got - data segment = an executable's data segment.
I believe the manpage was from the Open Group: http://pubs.opengroup.org/onlinepubs/009696799/functions/setrlimit.html The Solaris manpage changed it to: RLIMIT_DATA The maximum size of a process's heap in bytes. The brk(2) function will fail with errno set to ENOMEM. Ref: http://docs.oracle.com/cd/E23824_01/html/821-1463/setrlimit-2.html And the AIX manpage changed it to: RLIMIT_DATA The maximum size, in bytes, of the data region for a process. Ref: http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.basetechref%2Fdoc%2Fbasetrf1%2Fgetrlimit_64.htm So some Unix vendors noticed the problem of process vs binary executable and the meaning of data segment, and thus they changed the definition of RLIMIT_DATA in their manpages. IMO, if we could change DRMAA2_DATA_SEG_SIZE to DRMAA2_DATA_SIZE then we can remove the confusion, and also would give the application developers a more familar definition (ie. from their past setrlimit experience). But I am not strongly against it as the Linux manpage is also using data segment for initialized data, uninitialized data, and heap. Rayson On Thu, May 24, 2012 at 10:14 AM, Roger Brobst <[email protected]> wrote: > My recommendation is to clarify the DRMMA document by specifying that the > "process's data segment" includes: initialized data, uninitialized data, and > heap. It would not be unreasonable for someone to interpret "data > segment" as only initialized and uninitialized data (both known at > linktime). > > -Roger > > > -------- Original Message -------- > Subject: Re: [DRMAA-WG] DRMAAv2 C binding - "DRMAA2_TRUE64"? > From: Daniel Gruber <[email protected]> > To: Peter Tröger <[email protected]> > Cc: "[email protected]" <[email protected]> > Date: 05/24/2012 01:54 AM > > 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 <[email protected]> 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<[email protected]> 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 > [email protected] > https://www.ogf.org/mailman/listinfo/drmaa-wg > > > -- > drmaa-wg mailing list > [email protected] > https://www.ogf.org/mailman/listinfo/drmaa-wg > > > -- > drmaa-wg mailing list > [email protected] > https://www.ogf.org/mailman/listinfo/drmaa-wg > > > > > -- > drmaa-wg mailing list > [email protected] > https://www.ogf.org/mailman/listinfo/drmaa-wg -- drmaa-wg mailing list [email protected] https://www.ogf.org/mailman/listinfo/drmaa-wg
