linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Clements <paul.clements@steeleye.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: jejb@steeleye.com, linux-raid@vger.kernel.org
Subject: Re: [ANNOUNCE][PATCH 2.6] md: persistent (file-backed) bitmap and async writes
Date: Tue, 21 Sep 2004 15:19:03 -0400	[thread overview]
Message-ID: <41507EA7.1000905@steeleye.com> (raw)
In-Reply-To: <414F9FD4.4070308@steeleye.com>

Paul Clements wrote:
> OK, here we go again. The patch has been updated to 2.6.9-rc2 and mdadm 
> 1.7.0, and I've implemented the suggestions you've made below...
> 
> Patches: http://parisc-linux.org/~jejb/md_bitmap/

Well, I ran some simple write performance benchmarks today and I was 
stunned to find the bitmap performance was terrible. After debugging a 
while, I realized the problem was having the bitmap daemon do the 
wait_on_page_writeback...if the daemon got caught at the wrong time, it 
could take quite a while to come back around and do the writeback. So, I 
added yet another thread, the bitmap writeback daemon (whose sole 
purpose is to wait for page writebacks) and now things are running 
excellently. My simple benchmarks, which previously showed about a 
25-30% slowdown when using a bitmap vs. not using one, now show only a 
4% slowdown, which is pretty close to the margin of error in the test 
itself. Check out the new patch here:

http://parisc-linux.org/~jejb/md_bitmap/md_bitmap_2_37_2_6_9_rc2.diff

Thanks again,
Paul



> Neil Brown wrote:
> 
>> This is definitely heading in the right direction.  However I think
>> you have missed some of the subtleties of plugging.
> 
> 
> [snip]
> 
>> That should then have the bitmap updates happening before the
>> data updates, and should cluster bitmap updates better.
> 
> 
> OK, I've fixed that.
> 
>> The next step would be to stop write_page from being synchronous - I'm
>> not comfortable about ->unplug-fn having to wait for disk io.
> 
> 
> Well, it still does have to wait for the bitmap writes to complete 
> before letting the regular writes go, but I see your point about the 
> writes being submitted simultaneously (nearly) rather than being 
> completely serialized.
> 
>> This looks to be quite awkward as there is not call-back that happens
>> when writeback on a page is completed.  You need to have a kernel
>> thread to wait for the pages to complete.  I would get the
>> bitmap_daemon to do this.
> 
> 
> OK, this is what I've done...there didn't seem to be a better place to 
> do it.
> 
>> Does that make sense?
> 
> 
> Certainly does, and seems to work...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


  reply	other threads:[~2004-09-21 19:19 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-29 22:51 [ANNOUNCE][PATCH 2.6] md: persistent (file-backed) bitmap and async writes Paul Clements
2004-01-30 22:52 ` Paul Clements
2004-02-09  2:51 ` Neil Brown
2004-02-09 19:45   ` Paul Clements
2004-02-10  0:04     ` Neil Brown
2004-02-10 16:20       ` Paul Clements
2004-02-10 16:57       ` Paul Clements
2004-02-13 20:58       ` Paul Clements
2004-03-05  5:06         ` Neil Brown
2004-03-05 22:05           ` Paul Clements
2004-03-31 18:38             ` Paul Clements
2004-04-28 18:10               ` Paul Clements
2004-04-28 18:53                 ` Peter T. Breuer
2004-04-29  8:41               ` Neil Brown
2004-05-04 20:08                 ` Paul Clements
2004-06-08 20:53                 ` Paul Clements
2004-06-08 22:47                   ` Neil Brown
2004-06-14 23:39                   ` Neil Brown
2004-06-14 23:59                     ` James Bottomley
2004-06-15  6:27                   ` Neil Brown
2004-06-17 17:57                     ` Paul Clements
2004-06-18 20:48                     ` Paul Clements
2004-06-23 21:48                     ` Paul Clements
2004-06-23 21:50                       ` Paul Clements
2004-07-06 14:52                       ` Paul Clements
     [not found]                       ` <40F7E50F.2040308@steeleye.com>
     [not found]                         ` <16649.61212.310271.36561@cse.unsw.edu.au>
2004-08-10 21:37                           ` Paul Clements
2004-08-13  3:04                             ` Neil Brown
2004-09-21  3:28                               ` Paul Clements
2004-09-21 19:19                                 ` Paul Clements [this message]
2004-10-12  2:15                                   ` Neil Brown
2004-10-12 14:06                                     ` Paul Clements
2004-10-12 21:16                                       ` Paul Clements
2004-11-10  0:37                                     ` md: persistent (file-backed) bitmap Neil Brown
2004-11-10 18:28                                       ` Paul Clements

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=41507EA7.1000905@steeleye.com \
    --to=paul.clements@steeleye.com \
    --cc=jejb@steeleye.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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).