[DRMAA-WG] DRMAAv2 C binding - "DRMAA2_TRUE64"?
Rayson Ho
rayrayson at gmail.com
Thu May 24 15:41:26 EDT 2012
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 <rogerb at cadence.com> 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 <dgruber at univa.com>
> To: Peter Tröger <peter at troeger.eu>
> Cc: "drmaa-wg at ogf.org" <drmaa-wg at ogf.org>
> 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 <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
>
>
> --
> 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