On Fri, 8 Apr 2005, Tim Jenness wrote:
> On Fri, 8 Apr 2005, Peter W. Draper wrote:
>
> > In general as you approach the 2Gb limit under i386 it seems that our
> > programs behave quite differently. All too many seem to enter CPU bound
> > states (this may be down to atask signal handling) the others generally
> > make some garbled response showing a negative integer as the amount of
> > memory not mapped, or crash.
> >
> > On the bright-side under x86_64, I have created and mapped in HDS
> > components at addresses beyond 1.6Gb in an NDF, and GAIA has displayed an
> > NDF of size 3.2Gb, nothing else seemed to want to look at that, however!
> >
>
> Won't some of this go away if the offseting code for mmap consistently
> usese a BIGINT rather than an int?
Possibly, but only for the C code. The odd negative integer reported in
error messages seemed to be sign wrapped INTEGER*4s. Those kinds of issue
in Fortran will need more work than just adding large file support.
> Also, do you want to comment on my mmap64 suggestion?
Just to say that under most i386 Linux kernels the mmapped memory is
currently limited to 2Gb anyway (this is a sub-part of the 4Gb is used as
3Gb user -versus 1Gb system split used by the stock kernels), so it's not
likely to lead to any immediately useful features. Things look better
under Solaris, but we could just switch to 64 bit under that anyway. Not
saying we shouldn't do large file support anyway, but the urgency isn't
clear and we were targetting just up to 2Gb this time.
Cheers,
Peter.
|