httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: Memory usage and freeing
Date Mon, 20 Jan 1997 16:13:26 GMT
Jason S. Clary wrote:
> 
> 
> 
> Someone had mentioned that one of the reasons you guys use pool allocation is
> because memory is not truely freed to the system until a process exits so you
> re-use the
> same allocated memory by pool allocating it.

No, that's not a reason we are using pool allocation. The reason is to stop
memory leaks.

The "memory not truly freed" argument is an excuse for not freeing the pool
memory.

> 
> I was wondering if this is true of all systems.  I've been fiddling with it
> here and
> as far as I can tell linux seems to say the memory is available as soon as I
> free it... but maybe I'm missing something..

Linux presumably only makes the memory available if it happens to be at the
top of the heap.

> 
> Also, I've been wondering about this multithreading stuff.. I know that people
> keep saying one of the big speed savers in multithreading is that it doesn't
> have to reload the process and allocate all new stuff.. but I've been told
> that
> linux uses a copy-on-write procedure for fork()'d processes so it doesn't
> actualy generate any new stuff when you fork until you actualy modify data.
> 
> Are there other benefits to threading (other than running only a single
> process,
> which is nice) that I don't know about?  I've been playing with the pthreads
> package
> of late and it looks nice, but I still don't see where its supposed to be
> so much faster than using fork()...  I know that a lot of unix systems don't
> do such a minimal copy on fork like linux does, so maybe its more of an issue
> on other machines.. or maybe there's something else besides that that
> makes it faster.

The other thing that makes it faster is the saving on context switches. Thread
context switching is considerably cheaper than process context switching.

> 
> I do, however, prefer the notion of starting a single process and threadding a
> particular
> function.. I've done this quite a bit when programming for NT.. And it allows
> you
> to share data and syncronize between threads which is nice for seeing what
> is actualy going on.. but.. this is where it ties in with the topic of this
> message...
> If what was said about memory allocation is true, won't this mean that if your
> server
> is hit hard for an hour or so then goes back to normaly low hit rates it will
> still
> have a ton of memory not freed to the system?   Or does the pthread_terminate
> work similar to exit() in that case..

Since memory can only be freed when it is at the top of the heap, there are
likely to be problems reducing the size of the heap in a multithreaded server.

At least, traditionally memory can only be freed at the top of the heap - I'm
not aware of any Unix that allows holes - but perhaps Linux does?

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Mime
View raw message