Re: squid-novm and squid

On Wed, May 03, 2000, Henrik Nordstrom wrote:
> Adrian Chadd wrote:
>
> > Any hints why? I'd rather not try to find the relevant messages in amongst
> > the archives..
>
> Because the old memory manager locked in-transit objects fully in
> memory. It could not "swap in on demand" like the current one. It was
> primarily memory based. The design was then changed to see the disk as
> the "primary" source, and memory a voilatile resource.

Aha. Right, that makes sense. I was trying to find the code to reswapin
bits of an object that had been freed, and couldn't find it.

> You should probably separate on hot-cache and in-transit objects. The
> usage pattern of the two is quite different, and it is not good if
> in-transit "always" flushes the hot-object cache like it is done today..
>
> The complicated in-transit case is when there is two clients listening
> to the same large object (thing ISO image or other objects hundreds of
> MB in size) at different speeds. How to decide on what parts of memory
> to reclaim for other uses until the second client catches up?

Thats going to be an interesting problem to solve. I'm thinking of
implementing my page-based storage manager. What I envisange is the
storage memory manager acts as a pager, able to page parts of objects
in and out of memory. Once this is done, handling different types of
objects becomes easier, because then I can sit down and play with
different types of page replacement algorithms. This kills the concet
of a 'hot object cache', and nifty things can be done (the very first
thing I will implement when this vapourware code takes physical form
is to try to keep the beginning of objects in RAM so the client can be
sent data while an object page read is scheduled.

Right now however I'm going to work on optimising some other areas of the
codebase before rewriting the storage manager.

Thanks,

Adrian
Received on Wed May 03 2000 - 14:38:38 MDT