From: Ric Wheeler <rwheeler@redhat.com>
To: Josef Bacik <jbacik@redhat.com>
Cc: linux-ext4@vger.kernel.org, adilger@sun.com
Subject: Re: transaction batching performance & multi-threaded synchronous writers
Date: Tue, 15 Jul 2008 18:33:23 -0400 [thread overview]
Message-ID: <487D25B3.3030209@redhat.com> (raw)
In-Reply-To: <20080715204356.GE30311@unused.rdu.redhat.com>
Josef Bacik wrote:
> On Tue, Jul 15, 2008 at 04:10:10PM -0400, Josef Bacik wrote:
>
>> On Tue, Jul 15, 2008 at 02:39:04PM -0400, Josef Bacik wrote:
>>
>>> On Mon, Jul 14, 2008 at 12:15:23PM -0400, Ric Wheeler wrote:
>>>
>>>> Here is a pointer to the older patch & some results:
>>>>
>>>> http://www.spinics.net/lists/linux-fsdevel/msg13121.html
>>>>
>>>> I will retry this on some updated kernels, but would not expect to see a
>>>> difference since the code has not been changed ;-)
>>>>
>>>>
>>> Ok here are the numbers with the original idea I had proposed.
>>>
>>> type threads base patch speedup
>>> sata 1 17.9 17.3 0.97
>>> sata 2 33.2 34.2 1.03
>>> sata 4 58.4 63.6 1.09
>>> sata 8 78.8 80.8 1.03
>>> sata 16 94.4 97.6 1.16
>>>
>>> ram 1 2394.4 1878.0 0.78
>>> ram 2 989.6 2041.1 2.06
>>> ram 4 1466.1 3201.8 2.18
>>> ram 8 1858.1 3362.8 1.81
>>> ram 16 3008.0 3227.7 1.07
>>>
>>> I've got to find a fast disk array to test this with, but the ramdisk results
>>> make me happy, though they were kind of irratic, so I think the fast disk array
>>> will be a more stable measure of how well this patch does, but it definitely
>>> doesn't hurt the slow case, and brings stability to the fast case. Thanks much,
>>>
>>>
>> Hmm talking with ric I should just leave the single thread stuff alone. That
>> removes the slight speed regression seen above. Thanks,
>>
>>
>
> Here are the results with the single thread stuff put back in and with 250HZ
> instead of 1000HZ from before
>
> type threads base patch
> sata 1 21.8 21.6
> sata 2 26.2 34.6
> sata 4 48.0 58.0
> sata 8 70.4 75.2
> sata 16 89.6 101.1
>
> ram 1 2505.4 2422.0
> ram 2 463.8 3462.3
> ram 4 330.4 3653.9
> ram 8 995.1 3592.4
> ram 16 1335.2 3806.5
>
> Thanks,
>
> Josef
>
These numbers are pretty impressive - we need to get a run on an array
backed file system as well to round out the picture and possibly an SSD
(anyone have one out there to play with)?
ric
prev parent reply other threads:[~2008-07-15 22:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-14 16:15 transaction batching performance & multi-threaded synchronous writers Ric Wheeler
2008-07-14 16:58 ` Josef Bacik
2008-07-14 17:26 ` Ric Wheeler
2008-07-15 7:58 ` Andreas Dilger
2008-07-15 11:29 ` Ric Wheeler
2008-07-15 12:51 ` Josef Bacik
2008-07-15 14:05 ` Josef Bacik
2008-07-15 14:22 ` Ric Wheeler
2008-07-15 18:39 ` Josef Bacik
2008-07-15 20:10 ` Josef Bacik
2008-07-15 20:43 ` Josef Bacik
2008-07-15 22:33 ` Ric Wheeler [this message]
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=487D25B3.3030209@redhat.com \
--to=rwheeler@redhat.com \
--cc=adilger@sun.com \
--cc=jbacik@redhat.com \
--cc=linux-ext4@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 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).