From dev-return-5584-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Jan 28 17:10:58 2002 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 13500 invoked by uid 500); 28 Jan 2002 17:10:58 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 13485 invoked from network); 28 Jan 2002 17:10:57 -0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Mon, 28 Jan 2002 10:10:56 -0700 From: "Brad Nicholes" To: ,, Cc: Subject: RE: APR pool maintains too much free list Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 500/1000/N This would be great for NetWare. We have had to stick with malloc and free because there wasn't a way of freeing up the memory pools short of killing the process. Since NetWare only supports threads and therefore only runs a single instance of the server, killing the server just to clean up memory is a bit of a problem. If the memory pools had a way of doing garbage collection so that we don't end up with a lot of unused memory laying around, that would be great. Brad >>> "Sander Striker" Monday, January 28, 2002 9:50:33 AM >>> [...] > >There is that, although I must admit that I have a 'hi free' > >patch lying around. The idea is to free() all mem on the freelist > >when the freelist size goes over a certain threshold (like a few > >MB). I would need some feedback on this though, > > > > The high free threshold would be useful in at least one > place that I can think of in Apache. If we change the > worker MPM so that each worker threads can own a persistent > pool (and clear it, rather than destroying it, after each > request), then it would be good to have a mechanism that > sets the max size of a pool's free list following > apr_pool_clear(). E.g., I'd want to configure each ptrans > pool to keep three 8KB blocks in its allocator, for a total > of 24KB, in order to avoid mallocs on the next request most > of the time; but if the last request allocated 10MB within > the pool, we should return most of that space to the system > heap. > > But IMHO the only time when we should apply the high free > threshold is when destroying or clearing a pool. And that is how it works. > --Brian Sander