All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: packing structures and numbers
Date: Fri, 03 Oct 2008 16:40:26 +0300	[thread overview]
Message-ID: <48E620CA.1030008@redhat.com> (raw)
In-Reply-To: <1223036573.6836.19.camel@think.oraclecorp.com>

Chris Mason wrote:
> On Fri, 2008-10-03 at 14:42 +0300, Avi Kivity wrote:
>   
>> I've been reading btrfs's on-disk format, and two things caught my eye
>>
>> - attribute((packed)) structures everywhere, often with misaligned 
>> fields.  This conserves space, but can be harmful to in-memory 
>> performance on some archs.
>>     
>
> packed is important to make sure that a given field takes exactly the
> same amount of space everywhere, regardless of compiler optimization or
> arch.
>   

Yes, of course.

>> - le64's everywhere.   This scales nicely, but wastes space.  My home 
>> directory is unlikely to have more than 4G objects or 4GB extents (let 
>> alone >2 devices).
>>
>> I think the two issues can be improved by separating the on-disk format 
>> and the in-memory structure, and by using uleb128 as the on-disk format 
>> for numbers.  uleb128 is a variable-length format that encodes 7 bits of 
>> a number in each byte, using the eighth bit as a stop bit.
>>
>>     
>
> This couldn't be used everywhere, as the array of items headers and keys
> need to be a fixed sized the current bin_search code.  The items can be
> variable sized but in general they don't have as many le64s.
>
>   

You'd decode the keys and headers before searching.  This of couse 
negates the idea behind a binary search, unless you cache the decoded nodes.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


  reply	other threads:[~2008-10-03 13:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 11:42 packing structures and numbers Avi Kivity
2008-10-03 12:22 ` Chris Mason
2008-10-03 13:40   ` Avi Kivity [this message]
2008-10-04  0:22   ` Daniel Phillips
2008-10-04  0:28     ` Chris Mason
2008-10-04  0:35       ` Daniel Phillips
2008-10-04  0:43       ` Daniel Phillips
2008-10-04  8:27         ` Avi Kivity
2008-10-03 18:37 ` Zach Brown
2008-10-04  8:31   ` Avi Kivity
2008-10-04 16:34     ` Andi Kleen
2008-10-05  5:31       ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48E620CA.1030008@redhat.com \
    --to=avi@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.