Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 02 Mar 2002 23:14:24 -0800
From: Brian Pane <bpane@pacbell.net>
Subject: Re: bucket api patch
To: dev@apr.apache.org
Message-id: <3C81CD50.6050309@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
References: 
 <Pine.LNX.4.44.0203030146010.31984-100000@deepthought.cs.virginia.edu>

Cliff Woolley wrote:

>On Sat, 2 Mar 2002, Brian Pane wrote:
>
>>The 8KB allocations are from apr_brigade_write().
>>
>
>Not all of them should be.  If they are, I forgot some changes.  All of
>the APR_BUCKET_BUFF_SIZE malloc()'s should have been changed to
>apr_bucket_alloc() calls, and those happen in foo_read() and
>apr_bucket_heap_make() and a handful of other places in addition to
>apr_brigade_write().  Though we might not be hitting many of those other
>spots since we have sendfile and mmap, etc.
>

You're right.  I just did some gdb'ing and found that the 8KB
allocs in my test case (a simple mod_include scenario) were
actually from the socket_read() function in apr_buckets_socket.c.
This test case didn't actually hit the apr_brigade_write()
8KB alloc.

>>These 8KB blocks imply a design constraint for
>>the bucket allocator: it can't quite be a simple
>>power-of-two allocator.
>>
>
>I'd thought about that.  We are of course free to pick whatever block
>sizes we want.... if we want a block size that's just a bit bigger than
>8KB, I don't see a problem with that.  Or we could just decrease
>APR_BUCKET_BUFF_SIZE a bit so that we stay inside our two-page (on most
>systems) 8KB boundary.  Either way's fine with me.
>

+1 on decreasing APR_BUCKET_BUFF_SIZE to fit the whole thing
within 8KB.

--Brian