[Bioclusters] (no subject)

[Dan Bolser]

On Tue, 30 Mar 2004, Tim Cutts wrote:

> 
> On 30 Mar 2004, at 19:00, Dan Bolser wrote:
> 
> > On Wed, 31 Mar 2004, LAI Loong Fong wrote:
> >
> >> Hmm strange that you are getting 2GB per process, my large job 
> >> normally
> >> died around the 3GB on a standard linux kernel. Size of swap got
> >> nothing to do with this limit especially when you already has 4GB of
> >
> > This was just a rumour I heard about true64. Kernel limits physical 
> > memory
> > to the size of the swap for some reason.
> 
> I think you are referring to Tru64's two methods of swap allocation.  
> There is a kernel tunable parameter in Tru64 called vm_swap_eager.  
> This can be set to one of two modes.
> 
> As I understand it, it works like this:
> 
> Most programs allocate far more memory than they use.  This can cause 
> problems, so most operating systems overcommit memory and swap.  The 
> problem with this approach is that if you malloc a lot of memory, the 
> malloc may succeed, but when you later try to use it, the OS cannot 
> fulfil its promises, and really nasty things happen.
> 
> Tru64 can operate in this way, just like other operating systems (and 
> is the way we have it set).  But it might be set to its alternative 
> mode, whereby malloc actually immediately allocates from swap.  If 
> there isn't sufficient swap available, the malloc fails immediately.  
> In this mode, memory allocated is *guaranteed* to be available to the 
> application, which for certain applications can make things more 
> reliable.  The machine will never run out of memory at a time other 
> than at the point of memory allocation.
> 
> I seem to remember that IRIX has a similar tunable parameter for memory 
> use.

Thanks for this explaination, it makes sense now. I thought it might be
more than a concidence that our xeon appears to have a 2gb per process
limit and 2gb swap.

Can anyone suggest a smarter testing program (using malloc for
example) which can better probe the per process limit?

I will give it a google...

Cheers,
Dan.



> 
> Tim
> 
>