* Btrfs experimental branch updates
@ 2009-03-13 15:56 Chris Mason
2009-03-13 22:52 ` Steven Pratt
2009-03-15 19:13 ` Grigory Makarevich
0 siblings, 2 replies; 9+ messages in thread
From: Chris Mason @ 2009-03-13 15:56 UTC (permalink / raw)
To: linux-btrfs
Hello everyone,
I've rebased the experimental branch to include most of the
optimizations I've been working on.
The two major changes are doing all extent tree operations in delayed
processing queues and removing many of the blocking points with btree
locks held.
In addition to smoothing out IO performance, these changes really cut
down on the amount of stack btrfs is using, which is especially
important for kernels with 4k stacks enabled (fedora).
-chris
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-13 15:56 Btrfs experimental branch updates Chris Mason
@ 2009-03-13 22:52 ` Steven Pratt
2009-03-14 1:33 ` Chris Mason
2009-03-15 19:13 ` Grigory Makarevich
1 sibling, 1 reply; 9+ messages in thread
From: Steven Pratt @ 2009-03-13 22:52 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
Chris Mason wrote:
> Hello everyone,
>
> I've rebased the experimental branch to include most of the
> optimizations I've been working on.
>
> The two major changes are doing all extent tree operations in delayed
> processing queues and removing many of the blocking points with btree
> locks held.
>
> In addition to smoothing out IO performance, these changes really cut
> down on the amount of stack btrfs is using, which is especially
> important for kernels with 4k stacks enabled (fedora).
>
>
Well, no drastic changes. On Raid, creates got better, but random write
got worse. Mail server was mixed. For single disk, pretty much the same
story, although CPU savings is noticeable on write, although at the
expense of performance.
Raid graphs and links:
http://btrfs.boxacle.net/repository/raid/history/History.html
Single disk graphs and links:
http://btrfs.boxacle.net/repository/single-disk/History/History.html
Steve
> -chris
>
>
> --
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-13 22:52 ` Steven Pratt
@ 2009-03-14 1:33 ` Chris Mason
2009-03-15 14:38 ` Steven Pratt
0 siblings, 1 reply; 9+ messages in thread
From: Chris Mason @ 2009-03-14 1:33 UTC (permalink / raw)
To: Steven Pratt; +Cc: linux-btrfs
On Fri, 2009-03-13 at 17:52 -0500, Steven Pratt wrote:
> Chris Mason wrote:
> > Hello everyone,
> >
> > I've rebased the experimental branch to include most of the
> > optimizations I've been working on.
> >
> > The two major changes are doing all extent tree operations in delayed
> > processing queues and removing many of the blocking points with btree
> > locks held.
> >
> > In addition to smoothing out IO performance, these changes really cut
> > down on the amount of stack btrfs is using, which is especially
> > important for kernels with 4k stacks enabled (fedora).
> >
> >
> Well, no drastic changes. On Raid, creates got better, but random write
> got worse. Mail server was mixed. For single disk, pretty much the same
> story, although CPU savings is noticeable on write, although at the
> expense of performance.
>
Thanks for running this, but the main performance fixes for your test
are still in testing locally. One thing that makes a huge difference on
the random write run is to mount -o ssd.
-chris
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-14 1:33 ` Chris Mason
@ 2009-03-15 14:38 ` Steven Pratt
2009-03-17 1:24 ` Chris Mason
0 siblings, 1 reply; 9+ messages in thread
From: Steven Pratt @ 2009-03-15 14:38 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
Chris Mason wrote:
> On Fri, 2009-03-13 at 17:52 -0500, Steven Pratt wrote:
>
>> Chris Mason wrote:
>>
>>> Hello everyone,
>>>
>>> I've rebased the experimental branch to include most of the
>>> optimizations I've been working on.
>>>
>>> The two major changes are doing all extent tree operations in delayed
>>> processing queues and removing many of the blocking points with btree
>>> locks held.
>>>
>>> In addition to smoothing out IO performance, these changes really cut
>>> down on the amount of stack btrfs is using, which is especially
>>> important for kernels with 4k stacks enabled (fedora).
>>>
>>>
>>>
>> Well, no drastic changes. On Raid, creates got better, but random write
>> got worse. Mail server was mixed. For single disk, pretty much the same
>> story, although CPU savings is noticeable on write, although at the
>> expense of performance.
>>
>>
>
> Thanks for running this, but the main performance fixes for your test
> are still in testing locally. One thing that makes a huge difference on
> the random write run is to mount -o ssd.
>
>
Tried a run with -o ssd on the raid system. It made some minor
improvements in random write performance. Helps more on odirect, but
mainly at the 16thread count. Single and 128 threads it doesn't make
much difference.
Results syncing now to history boxacle
http://btrfs.boxacle.net/repository/raid/history/History.html
Steve
> -chris
>
>
> --
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-13 15:56 Btrfs experimental branch updates Chris Mason
2009-03-13 22:52 ` Steven Pratt
@ 2009-03-15 19:13 ` Grigory Makarevich
2009-03-16 13:31 ` Chris Mason
1 sibling, 1 reply; 9+ messages in thread
From: Grigory Makarevich @ 2009-03-15 19:13 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
Dear All,
I was wondering if the experimental branch is smth. different or it is
the same
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable-standalone.git
That repository does not seem to have any branches other than head and
master.
Thank you,
Best regards,
Grigory Makarevich
Chris Mason wrote:
> Hello everyone,
>
> I've rebased the experimental branch to include most of the
> optimizations I've been working on.
>
> The two major changes are doing all extent tree operations in delayed
> processing queues and removing many of the blocking points with btree
> locks held.
>
> In addition to smoothing out IO performance, these changes really cut
> down on the amount of stack btrfs is using, which is especially
> important for kernels with 4k stacks enabled (fedora).
>
> -chris
>
>
> --
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-15 19:13 ` Grigory Makarevich
@ 2009-03-16 13:31 ` Chris Mason
0 siblings, 0 replies; 9+ messages in thread
From: Chris Mason @ 2009-03-16 13:31 UTC (permalink / raw)
To: Grigory Makarevich; +Cc: linux-btrfs
On Sun, 2009-03-15 at 15:13 -0400, Grigory Makarevich wrote:
> Dear All,
>
> I was wondering if the experimental branch is smth. different or it is
> the same
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable-standalone.git
>
> That repository does not seem to have any branches other than head and
> master.
>
Unfortunately I still need to update the standalone tree. All of these
changes are only in the btrfs-unstable.git tree.
-chris
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-15 14:38 ` Steven Pratt
@ 2009-03-17 1:24 ` Chris Mason
2009-03-17 20:57 ` Steven Pratt
0 siblings, 1 reply; 9+ messages in thread
From: Chris Mason @ 2009-03-17 1:24 UTC (permalink / raw)
To: Steven Pratt; +Cc: linux-btrfs
On Sun, 2009-03-15 at 09:38 -0500, Steven Pratt wrote:
> > Thanks for running this, but the main performance fixes for your test
> > are still in testing locally. One thing that makes a huge difference on
> > the random write run is to mount -o ssd.
> >
> >
> Tried a run with -o ssd on the raid system. It made some minor
> improvements in random write performance. Helps more on odirect, but
> mainly at the 16thread count. Single and 128 threads it doesn't make
> much difference.
>
> Results syncing now to history boxacle
> http://btrfs.boxacle.net/repository/raid/history/History.html
Well, still completely different from my test rig ;) For the random
write run, yours runs at 580 trans/sec for btrfs and mine is going along
at 8000 trans/sec.
The part that confuses me is that you seem to have some big gaps where
just a single CPU is stuck in IO wait, and not much CPU time is in use.
Do you happen to have the blktrace logs for any of the btrfs runs? I'd
be interested in a script that did sysrq-w every 5s and captured the
output.
-chris
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-17 1:24 ` Chris Mason
@ 2009-03-17 20:57 ` Steven Pratt
2009-03-18 1:18 ` Chris Mason
0 siblings, 1 reply; 9+ messages in thread
From: Steven Pratt @ 2009-03-17 20:57 UTC (permalink / raw)
To: Chris Mason; +Cc: linux-btrfs
Chris Mason wrote:
> On Sun, 2009-03-15 at 09:38 -0500, Steven Pratt wrote:
>
>>> Thanks for running this, but the main performance fixes for your test
>>> are still in testing locally. One thing that makes a huge difference on
>>> the random write run is to mount -o ssd.
>>>
>>>
>>>
>> Tried a run with -o ssd on the raid system. It made some minor
>> improvements in random write performance. Helps more on odirect, but
>> mainly at the 16thread count. Single and 128 threads it doesn't make
>> much difference.
>>
>> Results syncing now to history boxacle
>> http://btrfs.boxacle.net/repository/raid/history/History.html
>>
>
> Well, still completely different from my test rig ;) For the random
> write run, yours runs at 580 trans/sec for btrfs and mine is going along
> at 8000 trans/sec.
>
That is odd. However, I think I have found 1 factor. In rerunning with
blktrace and sysrq an interesting thing happened. The results got a lot
faster. What I did was just run the 128 thread odirect random write
test. Instead of 2.8MB/sec, I got 17MB/sec. Still far below the 100+ of
ext4 and JFS, but one heck of a difference. Here is what I think is
going on. We make use of a flag in FFSB to reuse the existing fileset
if the fileset meets the setup criteria exactly. For the test I am
running that is 1024 100MB files. Since all of the random write test
are doing overwrites within the file, the file sizes do not change and
therefore the fileset is valid for reuse. For most Filesystems this is
fine, but with BTRFS COW, this will result in a very different file
layout at the start of each variation of the random write test. The
latest 128 thread was on a newly formatted FS. So...., I will do 2 new
runs tonight. First, I will re-mkfs before each random write test and
otherwise run as usual. Second, I plan on running the 128 threads test
multiple times (5 minute runs each) to see if it does really degrade
over time. What worries me is that for the case describer above, we
only have about 25 minutes of aging on the filesystem by the time we
execute th last random write test, which is not a whole lot.
> The part that confuses me is that you seem to have some big gaps where
> just a single CPU is stuck in IO wait, and not much CPU time is in use.
>
Yes, I have noticed that.
> Do you happen to have the blktrace logs for any of the btrfs runs? I'd
> be interested in a script that did sysrq-w every 5s and captured the
> output.
>
No, but as I mentioned above, I ran this today. Had a bug collecting
the sysrq, so I'll re-run tonight and post as soon as I can.
Steve
> -chris
>
>
>
>
> --
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Btrfs experimental branch updates
2009-03-17 20:57 ` Steven Pratt
@ 2009-03-18 1:18 ` Chris Mason
0 siblings, 0 replies; 9+ messages in thread
From: Chris Mason @ 2009-03-18 1:18 UTC (permalink / raw)
To: Steven Pratt; +Cc: linux-btrfs
On Tue, 2009-03-17 at 15:57 -0500, Steven Pratt wrote:
> Chris Mason wrote:
> > On Sun, 2009-03-15 at 09:38 -0500, Steven Pratt wrote:
> >
> >>> Thanks for running this, but the main performance fixes for your test
> >>> are still in testing locally. One thing that makes a huge difference on
> >>> the random write run is to mount -o ssd.
> >>>
> >>>
> >>>
> >> Tried a run with -o ssd on the raid system. It made some minor
> >> improvements in random write performance. Helps more on odirect, but
> >> mainly at the 16thread count. Single and 128 threads it doesn't make
> >> much difference.
> >>
> >> Results syncing now to history boxacle
> >> http://btrfs.boxacle.net/repository/raid/history/History.html
> >>
> >
> > Well, still completely different from my test rig ;) For the random
> > write run, yours runs at 580 trans/sec for btrfs and mine is going along
> > at 8000 trans/sec.
> >
> That is odd. However, I think I have found 1 factor. In rerunning with
> blktrace and sysrq an interesting thing happened. The results got a lot
> faster. What I did was just run the 128 thread odirect random write
> test. Instead of 2.8MB/sec, I got 17MB/sec. Still far below the 100+ of
> ext4 and JFS, but one heck of a difference. Here is what I think is
> going on. We make use of a flag in FFSB to reuse the existing fileset
> if the fileset meets the setup criteria exactly. For the test I am
> running that is 1024 100MB files. Since all of the random write test
> are doing overwrites within the file, the file sizes do not change and
> therefore the fileset is valid for reuse.
Oh! In that case you're stuck waiting to cache the extents already used
in a block group. At least I hope that's what sysrq-w will show us.
The first mods to a block group after a mount are slow while we read in
the free extents.
-chris
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-03-18 1:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-13 15:56 Btrfs experimental branch updates Chris Mason
2009-03-13 22:52 ` Steven Pratt
2009-03-14 1:33 ` Chris Mason
2009-03-15 14:38 ` Steven Pratt
2009-03-17 1:24 ` Chris Mason
2009-03-17 20:57 ` Steven Pratt
2009-03-18 1:18 ` Chris Mason
2009-03-15 19:13 ` Grigory Makarevich
2009-03-16 13:31 ` Chris Mason
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.