From: Miao Xie <miaox@cn.fujitsu.com>
To: Arne Jansen <sensille@gmx.net>
Cc: Andrey Kuzmin <andrey.v.kuzmin@gmail.com>,
Linux Btrfs <linux-btrfs@vger.kernel.org>,
Chris Mason <chris.mason@oracle.com>
Subject: Re: [RFC] Tree fragmentation and prefetching
Date: Thu, 24 Mar 2011 20:45:45 +0800 [thread overview]
Message-ID: <4D8B3CF9.4080306@cn.fujitsu.com> (raw)
In-Reply-To: <4D8AF2F5.7040108@gmx.net>
On thu, 24 Mar 2011 08:29:57 +0100, Arne Jansen wrote:
> On 24.03.2011 02:38, Miao Xie wrote:
>> On wed, 23 Mar 2011 21:28:25 +0100, Arne Jansen wrote:
>>> On 23.03.2011 20:26, Andrey Kuzmin wrote:
>>>> On Wed, Mar 23, 2011 at 4:06 PM, Arne Jansen<sensille@gmx.net> wrote:
>>>>> The main idea is to load the tree (or parts of it) top-down, order the
>>>>> needed blocks and distribute it over all disks.
>>>>> To keep you interested, some results first.
>>>>>
>>>>> a) by tree enumeration with reada=2
>>>>> reading extent tree: 242s
>>>>> reading csum tree: 140s
>>>>> reading both trees: 324s
>>>>>
>>>>> b) prefetch prototype
>>>>> reading extent tree: 23.5s
>>>>> reading csum tree: 20.4s
>>>>> reading both trees: 25.7s
>>>>
>>>> 10x speed-up looks indeed impressive. Just for me to be sure, did I
>>>> get you right in that you attribute this effect specifically to
>>>> enumerating tree leaves in key address vs. disk addresses when these
>>>> two are not aligned?
>>>
>>> Yes. Leaves and the intermediate nodes tend to be quite scattered
>>> around the disk with respect to their logical order.
>>> Reading them in logical (ascending/descending) order require lots
>>> of seeks.
>>
>> I'm also dealing with tree fragmentation problem, I try to store the leaves
>> which have the same parent closely.
>
> That's good to hear. Do you have already anything I can repeat the test
> with?
It is still under developing.;)
Thanks
Miao
> -Arne
>
>>
>> Regards
>> Miao
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-03-24 12:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 13:06 [RFC] Tree fragmentation and prefetching Arne Jansen
2011-03-23 15:01 ` Arne Jansen
2011-03-23 19:26 ` Andrey Kuzmin
2011-03-23 20:28 ` Arne Jansen
2011-03-23 21:47 ` Andrey Kuzmin
2011-03-24 1:38 ` Miao Xie
2011-03-24 7:29 ` Arne Jansen
2011-03-24 12:45 ` Miao Xie [this message]
2011-03-23 19:32 ` Chris Mason
2011-03-25 20:14 ` Arne Jansen
2011-03-25 20:15 ` Chris Mason
2011-03-25 20:53 ` Arne Jansen
2011-03-25 21:01 ` Chris Mason
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=4D8B3CF9.4080306@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=andrey.v.kuzmin@gmail.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sensille@gmx.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).