Re: #282: Recommend minimum sizes for protocol elements

On Fri, Jun 24, 2011 at 6:33 AM, Willy Tarreau <w@1wt.eu> wrote:
> On Fri, Jun 24, 2011 at 01:10:16AM -0700, Brian Pane wrote:
>> On Fri, Jun 24, 2011 at 12:26 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> > Haven't heard much. If we s/20k/4k/ in the header section, any other comments / suggestions / concerns?
>>
>> How about something like 4072 bytes instead of 4k?  That would give
>> the implementor some space for a length field and/or memory-management
>> bookkeeping inside the same page as the buffer, on systems with 4KB
>> pages.
>
> One specific value will never match all usages. For instance, I could
> store those pages in trees which need more than 24 bytes on 64-bit
> systems. The proposed value should be seen as a guideline to favor
> interoperability and nothing more.

I picked 24 bytes to allow for three pointers and/or counters on
64-bit systems, but I agree that a value larger than 24 would be a
good idea.  Given the prevalence of 64-byte cache lines, any number
between 1 byte and 63 bytes might as well be rounded up to 64 bytes.

> If an implementation makes use of
> 4kB pages and need 64 bytes for page management, resulting in 4032
> bytes, it will still be fine because the application which would
> complain about the missing 64 bytes will once in a while be hit by
> implementations respecting the 4096 bytes too.

Generally speaking, I'm not worried about wasted space within a page.
In every nontrivial server and proxy implementation I've seen, buffers
for received messages are allocated in relatively large units -
multiples of 4KB or 8KB, for example.  A request that fits within,
say, 1KB will automatically lead to internal fragmentation.  And
that's fine; it's a totally valid design tradeoff.  The resource I'm
most interested in conserving isn't actually memory, it's TLB entries.

With that in mind, what do you think about 4000 bytes?  It's a nice
round number, but it gives the implementor more flexibility than 4096.

-Brian

Received on Friday, 24 June 2011 16:32:19 UTC