Re: TLV to memPools

From: Adrian Chadd <adrian@dont-contact.us>
Date: Mon, 8 Oct 2001 09:32:40 -0600

On Mon, Oct 08, 2001, Andres Kroonmaa wrote:
>
> ok,
>
> Any good reason why we insist on size to be exactly size of
> pool's obj_size?
>
> /* free buffer allocated with memAllocBuf() */
> void
> memFreeBuf(size_t size, void *buf)
> {
> int i;
> MemPool *pool = NULL;
> assert(size && buf);
> for (i = 0; i < mem_str_pool_count; i++) {
> if (size <= StrPoolsAttrs[i].obj_size) {
> >>> assert(size == StrPoolsAttrs[i].obj_size);
> pool = StrPools[i].pool;
> break;
> }
> }
> memMeterDec(StrCountMeter);
> memMeterDel(StrVolumeMeter, size);
> pool ? memPoolFree(pool, buf) : xfree(buf);
> }

Hrm. Size and therefore pool predictability?

Hrm. Isn't there some general type API for this? Perhaps
in the string code? If not, you could whip up an API to do it.
I think thats something that may make things .. nicer.

Yes, something like this

struct memblock {
  char *buf;
  int size;
  pool_t pool;
  int allocated;
};

then, something like:

MEMBLOCK_PTR(memblock *) to get a char * or void * pointer to the memblock
MEMBLOCK_SIZE(memblock *) to get the max size (think string manipulation..)
memblock_alloc(memblock *, size) to allocate some RAM to the thing
memblock_realloc(memblock *, size) to reallocate some RAM to the thing
memblock_free(memblock *) to free the memblock
memblock_init() / memblock_done() to setup/delete the pools

This way, the memblock* routines can then decide which pool to stick
the data in and tuck the pool pointer away for future reabuse
when reallocating (allocate new blockin a new pool, memcopy, free
old one).

Instead of a

  char *buf; /* some buf */

in a struct or function decl, they could have:

  mempool_t mempool;

note that I'm using a static struct rather than a pointer - there's
no point in pooling the mempool_t entries, as they're minimal and
this would cut down on allocator overheads.

In fact, with this, I bet you could kill the rest of the mallocs in
the request code, the above code, maybe some evilnessen in the aufs
code, maybe some more evilness in the membuf code .. :-)

And yes, I'll most definitely commit this tidyup if someone gives me
a diff. :-)

Adrian
Received on Mon Oct 08 2001 - 09:32:41 MDT

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