phk malloc, was (Re: ptmalloc2)

Matthew Dillon dillon at apollo.backplane.com
Tue Feb 22 22:09:44 PST 2005


:Let's stop here then. The feature I am looking for doesn't come with
:Unix by default, beaten horse, etc.

    Any machine which is capable of paging data out to disk is going to 
    slow down once the load exceeds a certain point... that is, once the
    working set exceeds the amount of main memory available.  This is not
    the point where memory failures occur, this is the point where the
    machine starts to page to swap.  As the load increases past this point
    the paging load to swap increases dramatically.  SWAP does not have to
    fill up for the machine to become highly inefficient from load.  What
    is going to happen is that the efficiency of the services running on the
    machine will go down.  An email proxy, for example, which is capable of
    handling 200 connections per second may wind up being able to handle
    only 50 connections per second.

    This has nothing at all to do with having an overcommit knob.  An
    overcommit knob DOES NOT SAVE YOU from thrashing the machine.  Modern 
    machines configured with sufficient swap space will die a slow death
    long before swap fills up... long, long before an overcommit knob would
    come into play.  Overcommit is not a measure of the working set, it's a
    measure of avaiable SWAP space + available main memory.  It WILL NOT make
    programs run more efficiently, and it certainly will not make things
    more reliable.

    I hope I'm getting through to you here.  You do understand that your
    email proxy program is going to run the machine into the ground from
    paging long before turning off any overcommit knob would actually
    have an effect, don't you?

    Sysops always tune their machines to keep the working set within
    reasonable bounds, so the machine stays efficient.  It is fairly 
    obvious when a machine becomes inefficient due to paging load.  Memory
    allocation and overcommit has nothing at all to do with the problem.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list