Re: [squid-users] Memory pools: why use them?

On Thu, 2 Sep 2004, Robert Collins wrote:

> 1) If a suspected memory-corrupting bug is found in production, you can
> easily switch to the native memory allocator, or to one that uses
> free/alloc and is thus trackable by valgrind etc. Importantly you can do
> this even for systems running binaries without source experience. So we
> can get better bug reports.

Almost all the non-source users won't have debug symbols anyway, and very
few non-developers have valgrind.

It is fully possible to instrument the mempool allocator with the required
valgrind hooks, eleminating the need to switch allocator to use valgrind.
In addition these instrumentations is very light weight when not using
valgrind so it does not hurt performance much having these enabled.

> 2) different alloc strategies may make better sense for different
> classes. i.e. memory buffer classes may make sense as a direct
> alloc/free with caching, disk buffer classes may make sense as
> alloc/free with no caching and everything else via a slab allocator.
> Having multiple strategies available at runtime lets us do this in a
> clean manner.

Yes, but having this configurable in squid.conf just adds confusion.

> 3) different loads on a proxy may give us reason to switch strategies
> without taking the proxy down - this would require a more advanced
> implementation again - but could be done.

If so any such strategy selections should be automatic, not configuration
driven. If there can not be determined automatic algorithms it is
impossible for anyone to get them correct.

Regards
Henrik
Received on Thu Sep 02 2004 - 05:15:10 MDT