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

On Thu, 2004-09-02 at 13:15 +0200, Henrik Nordstrom wrote:
> 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.

This doesn't need to be in squid.conf... but it doesn't need to be
runtime configurable by the system.

> > 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.

Agreed.. that is what I was suggesting.

Rob