httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: httpd-2.0 STATUS
Date Fri, 12 Jan 2001 20:32:23 GMT

> >   +    * Mod_autoindex is still causing too many buckets and too many bucket
> >   +      brigades to be created.  We need to improve the way the old ap_r*
> >   +      functions interact with buckets.  This is being tabled until after
> >   +      the beta.
> >   +          See MSG: <Pine.LNX.4.21.0101111403150.1557-100000@koj>
> I had a whacky idea about this a little while ago.
> Consider: our main problem is the allocation of the brigade and the
> transient bucket. We use the transient bucket to defer copying until
> necessary. That is an important part, so we shouldn't lose that.
> Consider: ap_r* are NOT re-entrant. Across all the functions.
> Possible answer: "allocate" a brigade and a custom bucket type in the
> request_rec. ap_r* would fill in some values and pass the brigade down. If a
> set-aside occurs, then the custom bucket simply copies into heap bucket or
> whatever. During a set-aside, the brigade we pass won't be used because the
> code doing the set-aside can't know the pool the thing was allocated in, so
> we don't have to worry about the fixed structure in the request_rec. Since
> ap_r* aren't reentrant, again, we don't have to worry about the fixed
> structs in the request_rec.

I'm missing something here.  How does this keep us from creating buckets
that only refer to a couple of bytes?  I don't think the problem is the
number of brigades, it is the sheer number of buckets that we end up
malloc'ing.  If you call ap_r*, you will end up passing a single bucket
down the stack.  If a later filter calls the set-aside function, then we
will end up creating a corresponding heap bucket.  Unless the set-aside
function is going to try to coalesce, this doesn't solve the problem, it
just moves it from the ap_r* function to a point later in processing.

> What the above means is that ap_r* is no longer a factor in bucket/brigade
> optimizations. We have a low-cost solution to transform from old-style into
> the bucket-style. Then we just work on improving bucket operations.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message