so, yeah, about keeping you in the loop...

[Poul-Henning Kamp]

I'm still trying to get used to using the -dev list more:

I'm not quite sure if there were any consensus on the 3.1/4.0
naming issue, that one's still sort of open.

Arthur raised a point long time ago, which I have been ignoring
for far too long, but I've decided to tackle it now:

Varnish doesn't have a "struct req", but only a "struct sess".

Together with the session workspace and other stuff, that means
that we have a lot of memory sitting idle in the "waiter" in the
hope that the client sends us another request.

Fixing that will be major surgery, but fortunately, it is almost
entirely mechanical in the form of
        s/sp->foo/sp->req->foo/
substitutions.

I've been prototyping this massive text-editing exercise locally
and it seems like we can trivially get down to 512 bytes of memory
per session waiting for more requests.

One of the preparations for this and other changes, is that I have
tired of writing memory pool managers, and have started to write
the memory pool manager to manage all pools.

This gives us a consistent view of these pools, with parameters
and statistics we can hopefully draw benefits from.

A pool has a low and high watermarks and a idle-timeout.  A dedicated
per pool thread will preallocate/discard items to keep the pool
inside the watermarks.

The tricky thing about these pools is that they must be able to
allocate items of changing size:  If you decide you need a larger
workspace or more HTTP headers, that should be an on-the-fly
change not requiring a restart.  I think I have this covered,
but we'll see.

In the end I think the memory situation will be:

        N workerpools which each have:
                a bunch of worker threads
                a memory pool of "struct sess"
                a (smaller) memory pool of "struct req"
                        Co-allocated with workspace for req/resp

        A mempool for backend-connections "vbc"
        A mempool for busy objects "busyobj"
                Co-allocated with workspace for bereq/beresp
                (busyobj is the pivot for talking to the backend)

Stand by for some turbulence...

Ohh, and Merry X-mas everybody!

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.