--- Charu Pakar <charlie007000@yahoo.ca> wrote: > From the description
it would be better to restate the
> problem so that we can arrive at a generic solution.
> 
> Problem :
> 
> Irrespective of wether there is swap or not. How can
> one prevent the failure of a process, due to failuer
> to get real memory. Hence the use of calloc() in the
> test program.
> 
> Comments :
> 
> 1) Since RAM + SWAP is always finite in space, only
> processes which fit into the space provided will be
> supported by the OS.
> 
> 2) To alleviate the problems observed all UVM
> thersholds can be tweaked to move the window where the
> problem occurs eg increasing target free, but cannot
> be eliminated.
> 
> 3) The hidden question I suspect is "How do I prevent
> my process from dying due to a OS resource crunch ?".
> In most systems the expected behaviour is that some
> process will exit a some point in time thus release
> resources which will be made available. However what
> if my application is a bunch of processes which do not
> exit. Under such circumstances starting another
> process or an existing process would fail on a calloc
> if no resources are available.
> 
> 4) IMHO there is no generic kernel based solution if
> (3) is valid. There has to be some sort of strategy
> which is implemented across kernel+userland. When a
> resource crunch is detected the kernel needs to
> indicate to the processes to reduce their core size,
> thereby making space of the new process. This scheme
> can be evolved depending on the operational
> environment of the application.
> 
> The BSD gurus please correct anything incorrect.
> 
> Charu Palkar

I am not BSD guru, but 4) is no solution: supposed none of the programs
can reduce their core size? In the case of a malicious abuse, they
definately won't comply anyway. You could probably do it for embedded
systems (since you can guarantee what your apps will do hopefully), but
it would be an application-specific thing. 

The only "solution" available now would be to set resource limits to
guarantee that unpriviledged users cannot gobble memory, but then would
that stop "malloc() then fork() then write memory" programs (and
basically any program which fork()'s and does not exec())? If it did
work, would it defeat the purpose of allowing overcommit in the first
place by not allowing maximum usage of memory?

Resource limits would also be ineffective for daemons running as root
that try the "use more resources until requests fail" style of resource
management (advocated for fork() usage by some and which is probably
correct when the system tracks its resources properly), since malloc()
can succeed when it really should fail. 

> --
> 
>  --- Sylvain Fontaine <sfontaine@hyperchip.com> wrote:
> > 
> > I found a behavior with the UVM that seems to be
> > wrong.
> > My system has no swap space. 1G of RAM.
> > 
> > Here's what I see:
> > - Create a file of 100M on a MFS of 100M.  Then 200M
> > are removed from free,
> > 100M active, 100M file.
> >   I'm left with about 730M of free mem now, but with
> > 100M file memory
> > available when needed.
> > - I start a program that calloc (not malloc) 800M. 
> > I expect file memory to
> > be returned to me.
> >   The test program does callocation by 100M slices.
> > - The page deamon does not react until its
> > free_target is not under.  About
> > ~~500k.
> > - When the page deamon finds the free_target not to
> > be met, it starts
> > recovering pages, 
> >   but there's a race condition freeing/allocating
> > and my test app wins...
> > resulting in faulting
> >   and being killed by the UVM when uvm_fault returns
> > ENOMEM.  
> > 
> > 
> > I found two solutions:
> > 1) In this condition, when I know there is still
> > memory I can retrieve from
> > file memory,
> >     I call uvm_wait, and tell the pagedeamon to
> > overlook the free_target and
> > to free 
> >     some pages because I need some, even if the
> > free_target is met.
> > 2) Increraese the free target to 1/20 of my memory
> > ~50M... This way the race
> > begins sooner
> >     And the pagedeamon wins.
> > 
> > Sylvain
> > 
> >   
> > 
> > 
> >  
> 
> =====
> Charu Palkar
> --
> Email:charlie007000@yahoo.ca
>       cpalkar@sympatico.ca
> 
>
______________________________________________________________________
> 
> Post your free ad now! http://personals.yahoo.ca 

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca