linux-kernel - Re: [PATCH 0/6 v6][RFC] jbd[2]: enhance fsync performance when using CFQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100702202342.GH7001@redhat.com>
Date:	Fri, 2 Jul 2010 16:23:42 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	linux-ext4@...r.kernel.org, axboe@...nel.dk,
	linux-kernel@...r.kernel.org, tao.ma@...cle.com
Subject: Re: [PATCH 0/6 v6][RFC] jbd[2]: enhance fsync performance when using
 CFQ

On Fri, Jul 02, 2010 at 03:58:13PM -0400, Jeff Moyer wrote:

[..]
> Changes from the last posting:
> - Yielding no longer expires the current queue.  Instead, it sets up new
>   requests from the target process so that they are issued in the yielding
>   process' cfqq.  This means that we don't need to worry about losing group
>   or workload share.
> - Journal commits are now synchronous I/Os, which was required to get any
>   sort of performance out of the fs_mark process in the presence of a
>   competing reader.
> - WRITE_SYNC I/O no longer sets RQ_NOIDLE, for a similar reason.

Hi Jeff,

So this patchset relies on idling on WRITE_SYNC queues. Though in general
we don't have examples that why one should idle on processes doing WRITE_SYNC
IO because previous IO does not tell anything about the upcoming IO. I am
bringing up this point again to make sure that fundamentally we agree that
continue to idle on WRITE_SYNC is the right thing to do otherwise this patch
will fall apart.

I have yet to go through the patch in detail but allowing other queue to
dispatch requests in the same queue sounds like queue merging. So can
we use that semantics to say elv_merge_context() or elv_merge_queue()
instead of elv_yield(). In the code we can just merge the two queues when
the next request comes in and separate them out at the slice expiry I 
guess.

Thanks
Vivek

> - I did test OCFS2, and it does experience performance improvements, though
>   I forgot to record those.
> 
> Previous postings can be found here:
>   http://lkml.org/lkml/2010/4/1/344
>   http://lkml.org/lkml/2010/4/7/325
>   http://lkml.org/lkml/2010/4/14/394
>   http://lkml.org/lkml/2010/5/18/365
>   http://lkml.org/lkml/2010/6/22/338
> 
> [1] http://lkml.org/lkml/2010/6/21/307
> 
> [PATCH 1/6] block: Implement a blk_yield function to voluntarily give up the I/O scheduler.
> [PATCH 2/6] jbd: yield the device queue when waiting for commits
> [PATCH 3/6] jbd2: yield the device queue when waiting for journal commits
> [PATCH 4/6] jbd: use WRITE_SYNC for journal I/O
> [PATCH 5/6] jbd2: use WRITE_SYNC for journal I/O
> [PATCH 6/6] block: remove RQ_NOIDLE from WRITE_SYNC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/