Re: aiops.c and xmalloc

On Thu, Oct 05, 2000, Andres Kroonmaa wrote:
> On 5 Oct 2000, at 20:09, Adrian Chadd <adrian@creative.net.au> wrote:
> > > On 4 Oct 2000, at 20:41, Henrik Nordstrom <hno@hem.passagen.se> wrote:
> > >
> > > > > if ((requestp->path = (char *) xmalloc(len)) == NULL) {
> > > >
> > > > Purely old remains. Not needed today, but since it is there why removing
> > > > it..
> > >
> > > Because its confusing, and wasting space? Could we ever stop using xmalloc?
> > > While I hacked it, I ripped off these checks. Do you object that?
> > > I'll put them back if so.
>
> > I think they can be ripped out. in fact, I'd like to hazard a guess that
> > theoretically the only place we need to use xmalloc inside squid/src is
> > the mempool code itself. I would be happy if *everything* used the mempools
> > interface. :-)
>
> well, there is small problem with that. xmalloc is used for all sorts of
> variable sizes, which (size) cannot be determined at xfree() time, making
> it difficult to pick the right pool.
> with strings also, we could strlen() before freeing, but we must then be
> very sure that strlen hasn't changed meanwhile.

When you have a pool chosen at create time, you don't *NEED* its size
at free time. only its pool. I get your point though. I will work something
out soonish. In fact, I am pretty sure that a lot of those extraneous
buffer copies can go away - memory needed for a read or write op will
be supplied by a higher-up layer and is pretty much guaranteed to exist
until the end of the fileop anyway.

> > > > Of the 4 xmalloc calls there is in aiops, only one is easily
> > > > transferrable to memory pools.. (the struct stat one).
> > >
> > > Well, I moved all but path mallocs to Pools. Slightly higher mem usage,
> > > but less memory trashing on positive side. I think we can move path
> > > mallocs also to pools, and we can define more buftypes to get a better
> > > match to needed buffer sizes.
> > > But seems that aiops usage is very casual and low.
> >
> > Basing the bufs on DISK_PAGE_SIZE I think is rather wrong (and a hint, in
> > squid-dev DISK_PAGE_SIZE doesn't exist anymore - I killed it and am using
> > SM_PAGE_SIZE instead which is the storage manager pagesize and it makes
> > things slightly less convoluted.)
>
> hmm, SM_PAGE_SIZE must be small, but disk ops gain from large transfers.
> Does it mean that disk io is now SM_PAGE_SIZE sized?

why does SM_PAGE_SIZE have to be small?
Believe me, trying to aggregate SM_PAGE_SIZE into DISK_PAGE_SIZE chunks
is a little tedious. Well, no, i lie - the tediousness is wrapped in
a call to stmemCopy() which is one evil function I hope to soon destroy.

>
>
>
> ------------------------------------
> Andres Kroonmaa <andre@online.ee>
> Delfi Online
> Tel: 6501 731, Fax: 6501 708
> Pärnu mnt. 158, Tallinn,
> 11317 Estonia
>

-- 
Adrian Chadd			"If a butterfly flaps its wings in China,
<adrian@creative.net.au>	    will a woman get naked in Amsterdam?"
				      -- Ashley Penney on Chaos Theory