Thanks for the added information ... I did run strace and appear to be using
the latest libraries ... I'll bring the files home tomorrow and send them if
necessary. Incidently, although I have used mem= in lilo but have not
included it presently. I'll try this tomorrow.
Is there anything in the strace output you were looking for other than the
libraries? I noticed that it was outputting bk() values that I have seen in
memory discussions ...
Incidently, I use Portland compilers ... I have only mentioned g77 as a way
of comparing results. The Portland guy I exchanged email said that g77
imposes a hard limit on size ... but I still find this hard to believe since
I know a lot of people regularly use gcc and g77. Portland is licensed
software ... but allows a home use license and so both compilers are
identical versions running the same kernel (except the SMP kernel is used at
home on the dual processor machine).
I understand about swap and ram ... I do not understand the actual limits in
the kernel and how to find them. When I use a simple C code to retrieve the
resource limits (rlimit) I get 4G for the process size (ram+swap). However,
I had not run this on the big machine with the SMP kernel. I would have
thought that this would have retrieved the values that the kernel
I was wondering what you think about just upgrading my distribution to
Redhat 7.1 and the 2.4.? kernel ... ? Of course, I do have a never give up
More information tomorrow ..
> > Certainly, the BIOS recognizes the memory ... at least it checks it.
> > using the non-SMP kernel, top and free (and other ways to indicate
> > all indicate that I have 1.5G of memory and 2G of swap. Clearly, there
> > memory detection issue with the SMP kernel ... but then this is the only
> > time I've ever booted into this kernel ...
> The problem is the interfaces to the BIOS. A similar sort of thing
> with hard disk size detection, although linux bypassed the BIOS in that
> The main thing I was noting here
> > was that the f90 program acquired up to 2G rather than just the 1365 by
> > non-SMP kernel. Of course, when I checked the limits using ulimit, the
> > memory and file parameters were set at 4G ... so why wouldn't the f90
> > program acquire close to 3.5 G (the 1.5G ram and the 2G swap - minus
> > locked memory)?
> Again the physical memory (actual RAM) is different from VM. VM size is
> always the same for each process. ie you could have 100 processes taking
> up 1 Gig of VM space and only have 128Meg of RAM, you just be hitting swap
> The reason you don't get 4Gig for each process is that there is also the
> kernel involved. There all sorts of different patches that are not part
> the syandard kernel which allow the VM system deal with large process
> > Incidently, when I run the SMP at home on my dual PPRO with 128 ram and
> > swap ... and the same kernel ... everything works as expected and the
> > results are the same for both the f77 and f90 versions of the test code.
> > course, 128M is a far cry from 1.5 G.
> Again BIOS different so the memory detection may work. Is it the same
> version of the compilers. I don't use fortran myself so I don't known the
> history the the compilers.
> > What parameters (other than the normal ones that the shell commands give
> > access to) should I be looking for if I recompile the kernel (which I
> > haven't done in quite a while ...)
> One thing I didn't mention for the memory detection issue is that you can
> supply parameters to the kernel that can override the memory detection
> eg from lilo
> linux mem=XXXM