FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 09-17-2008, 03:47 PM
Bodo Eggert
 
Default dm-snapshot: poor copy-on-write performance due to I/O reordering

Kazuo Ito <ito.kazuo@oss.ntt.co.jp> wrote:

> Write throughput to LVM snapshot origin volume is an order
> of magnitude slower than those to LV without snapshots or
> snapshot target volumes, especially in the case of sequential
> writes with O_SYNC on.
>
> The following patch originally written by Kevin Jamieson and
> Jan Blunck and slightly modified for the current RCs by myself
> tries to improve the performance by modifying the behaviour
> of kcopyd, so that it pushes back an I/O job to the head of
> the job queue instead of the tail as process_jobs() currently
> does when it has to wait for free pages. This way, write
> requests aren't shuffled to cause extra seeks.

Did you check for starvation problems, too?

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-24-2008, 05:55 AM
Kazuo Ito
 
Default dm-snapshot: poor copy-on-write performance due to I/O reordering

Hello,

> Bodo Eggert wrote:
>> Kazuo Ito <ito.kazuo@oss.ntt.co.jp> wrote:
>>
>>> Write throughput to LVM snapshot origin volume is an order
>>> of magnitude slower than those to LV without snapshots or
>>> snapshot target volumes, especially in the case of sequential
>>> writes with O_SYNC on.
>>>
>>> The following patch originally written by Kevin Jamieson and
>>> Jan Blunck and slightly modified for the current RCs by myself
>>> tries to improve the performance by modifying the behaviour
>>> of kcopyd, so that it pushes back an I/O job to the head of
>>> the job queue instead of the tail as process_jobs() currently
>>> does when it has to wait for free pages. This way, write
>>> requests aren't shuffled to cause extra seeks.
>>
>> Did you check for starvation problems, too?

I have twice and four times as many pages allocated
to each kcopyd client without patching the queuing behaviour
and got these figures (MiB/s) -- allocating more buffers doesn't
seem to help much, so I don't think it's memory shortage
that matters here.

test # of buffer pages 256(default) 512 1024
10M dd+fsync, create 16.00 18.60 18.95
10M dd+fsync, update 16.14 18.39 19.70
100M dd+fsync, create 15.18 18.80 19.29
100M dd+fsync, update 15.28 19.29 19.45

--

Kazuo Ito, NTT Open Source Software Center
Phone: +81-3-5860-5125 / FAX: +81-3-5463-5690 / E-mail:
ito.kazuo@oss.ntt.co.jp


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 04:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org