Re: TLV to memPools

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Wed, 10 Oct 2001 01:30:42 +0200

On 9 Oct 2001, at 14:53, Henrik Nordstrom <hno@marasystems.com> wrote:

> Andres Kroonmaa wrote:
>
> > I'm all for using dedicated pools for things that are used often or
> > that are living long. The issue comes up with stuff that lives for
> > around 100 cpu ticks and whose max concurrent usage is 1 or 0. Do we
> > really need to create memPool for such, going to trouble doing so?
> > We have currently about 90 pools in squid, of which typically ever
> > used are 60, and on average inuse at a time of sampling are 50, and
> > about 10 pools are ever used for less than 10 allocs. We can convert
> > all allocs to dedicated pools, but would we care?
>
> For temporary things like TLV I am for not using any allocation as
> described before.

 right, so things like TLV needs to be rewritten.

> Everything that is allocated "dynamically" per request or whatever
> SHOULD either be pooled, or not allocated at all (i.e. static or stack
> allocation). And I don't like "generic/typeless" pools for typed data.
> Any typed data should have it's own pool.

 ok, so we have 2 votes for rejecting idea of abstract bestfit pool.

> I am for using dedicated pools at most locations. My view is also that
> short lived data of fixed length should be allocated statically or from
> the stack. Short lived data of varying length is a bit trickier but
> there is constructs like alloca() that some times makes sense.

 And a bit of emerging "Memory allocation guidelines" for squid.

> > I think that major compromise must be made here. I wouldn't even
> > object if it is decided "politically" to reject existence of abstract
> > pools. For some data this is unavoidable, like variable length bufs,
> > strings. But we can insist that each file implements its own set of
> > pools. If this makes sense.
>
> In the case of
> String
> MemBuf
> TLV
> I think it makes sense if each has it's own set of pools. This to allow
> them to be better tuned for the actual use, and to maintain
> understantable accounting of the allocations.

 I think that TLV can be skipped. We could write directly to MemBuf
 buffer packed data, and extract fields directly from buffer.
 Should we move memAllocBuf from mem.c away to Strings.c?

> > Shouldn't focus on TLV at all. There are lots of others similar.
>
> Name one that is similar to TLV on sizing, typing, scope and time.

 hmm, I meant "suitable for being use with bestfit pool".
 I didn't even think of any specific properties.
 Now covered by rejecting idea of bestfit pool.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Tue Oct 09 2001 - 17:37:35 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:32 MST