Re: #282: Recommend minimum sizes for protocol elements

On Fri, Jun 24, 2011 at 09:31:32AM -0700, Brian Pane wrote:
> 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.

As I explained, we could use either of these because whoever
experiences an issue with one of these will certainly experience
issues with the other one too at some point.

Sure we can go with a round 4000, I'm fine with this too.

Regards,
Willy

Received on Friday, 24 June 2011 18:02:54 UTC