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  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]
Date:	Tue, 6 Jan 2015 21:18:44 +0800
From:	Ming Lei <>
To:	Maxim Patlasov <>
Cc:, Dave Kleikamp <>,
	LKML <>,
	linux-fsdevel <>,
	Andrew Morton <>,
	Zach Brown <>
Subject: Re: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio_vec

On 1/6/15, Maxim Patlasov <> wrote:
> On 12/31/2014 04:52 PM, Ming Lei wrote:
>> On Thu, Jan 1, 2015 at 6:35 AM, Sedat Dilek <>
>> wrote:
>>> On Wed, Dec 31, 2014 at 10:52 PM, Dave Kleikamp
>>> <> wrote:
>>>> On 12/31/2014 02:38 PM, Sedat Dilek wrote:
>>>>> What has happened to that aio_loop patchset?
>>>>> Is it in Linux-next?
>>>>> ( /me started to play with "block: loop: convert to blk-mq (v3)", so I
>>>>> recalled this other improvement. )
>>>> It met with some harsh resistance, so I backed off on it. Then Al Viro
>>>> got busy re-writing the iov_iter infrastructure and I put my patchset
>>>> on
>>>> the shelf to look at later. Then Ming Lei submitted more up-to-date
>>>> patchset:
>>>> It looks like Ming is currently only pushing the first half of that
>>>> patchset. I don't know what his plans are for the last three patches:
>>>> aio: add aio_kernel_() interface
>>>> fd/direct-io: introduce should_dirty for kernel aio
>>>> block: loop: support to submit I/O via kernel aio based
>>> I tested with block-mq-v3 (for next-20141231) [1] and this looks
>>> promising [2].
>>> Maybe Ming can say what the plan is with the missing parts.
>> I have compared kernel aio based loop-mq(the other 3 aio patches
>> against loop-mq v2, [1]) with loop-mq v3, looks the data isn't
>> better than loop-mq v3.
>> kernel aio based approach requires direct I/O, at least direct write
>> shouldn't be good as page cache write, IMO.
>> So I think we need to investigate kernel aio based approach further
>> wrt. loop improvement.
> A great advantage of kernel aio for loop device is the avoidance of
> double caching: the data from page cache of inner filesystem (mounted on
> the loop device) won't be cached again in the page cache of the outer
> filesystem (one that keeps image file of the loop device).

Yes, I agree avoidance of double cache is very good, at least
page consumption can be decreased, avoid one copy and make the backed
file more like a 'block' device.

> So I don't think it's correct to compare the performance of aio based
> loop-mq with loop-mq v3. Aio based approach is OK as long as it doesn't
> introduce significant overhead as compared with submitting bio-s
> straightforwardly from loop device (or any other in-kernel user of
> kernel aio) to host block device.

One problem is that aio based approach requires O_DIRECT, and direct
write looks much slower compared with page cache write in my fio
test over loop block directly.

But it might not be so bad when write I/O is considered from
filesystem over loop block since there is still page cache and the
write I/O is often big chunk from file system. I will run tests inside
filesystem to compare the two approaches further.

Ming Lei
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists