All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Jamieson <kjamieson@bycast.com>
To: dm-devel@redhat.com
Subject: kcopyd performance
Date: Wed, 30 May 2007 15:56:42 -0700	[thread overview]
Message-ID: <465E012A.5080905@bycast.com> (raw)

Hi,

I've been investigating some performance issues with writes to a LVM2
snapshot origin volume being much slower than one would expect (i.e.,
10-50x slower for a logical volume with a single snapshot volume).

Using a simple dd test (I get similar numbers with other tools like
bonnie) on a P4 3GHz w/SATA disks (no RAID):

dd if=/dev/zero of=/vol/file bs=1M count=1000

Logical volume w/o snapshot: 45.4 MB/s
LV w/snapshot on same disk, chunksize=8K: 1.1 MB/s
LV w/snapshot on same disk, chunksize=512K: 4.0 MB/s
LV w/snapshot on separate disk, chunksize=8K: 1.2 MB/s
LV w/snapshot on separate disk, chunksize=512K: 5.6 MB/s

I tracked the main cause of the poor performance to the behaviour of
process_jobs() in kcopyd. If kcopyd's page pool has no free pages, it
moves the next job in the _pages_jobs list to the tail of the list.
New jobs are also added to the tail of the _pages_jobs list (in
dispatch_job()). This re-ordering of the I/Os results in a lot of extra
seek activity for workloads consisting of sequential writes.

The below patch modifies process_jobs() to push the job back to the head
of the list instead of the tail when there are no free pages. I see
significantly improved performance with this change:

LV w/snapshot on same disk, chunksize=8K: 9.6 MB/s
LV w/snapshot on same disk, chunksize=512K: 8.4 MB/s
LV w/snapshot on separate disk, chunksize=8K: 17.2 MB/s
LV w/snapshot on separate disk, chunksize=512K: 14.5 MB/s

Thanks,
Kevin


--- linux/drivers/md/kcopyd.c.bak	2007-05-30 14:18:36.000000000 -0700
+++ linux/drivers/md/kcopyd.c	2007-05-30 15:54:33.000000000 -0700
@@ -280,6 +280,15 @@
 	spin_unlock_irqrestore(&_job_lock, flags);
 }
 
+static inline void push_head(struct list_head *jobs, struct kcopyd_job *job)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&_job_lock, flags);
+	list_add(&job->list, jobs);
+	spin_unlock_irqrestore(&_job_lock, flags);
+}
+
 /*
  * These three functions process 1 item from the corresponding
  * job list.
@@ -404,7 +413,7 @@
 			 * We couldn't service this job ATM, so
 			 * push this job back onto the list.
 			 */
-			push(jobs, job);
+			push_head(jobs, job);
 			break;
 		}
 

 

                 reply	other threads:[~2007-05-30 22:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=465E012A.5080905@bycast.com \
    --to=kjamieson@bycast.com \
    --cc=dm-devel@redhat.com \
    /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.