linux-kernel - Re: [PATCH 2/2] cfq: allow dispatching of both sync and async I/O together

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: <4C1FC4B4.3060700@kernel.dk>
Date:	Mon, 21 Jun 2010 21:59:48 +0200
From:	Jens Axboe <axboe@...nel.dk>
To:	Jeff Moyer <jmoyer@...hat.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] cfq: allow dispatching of both sync and async I/O
 together

On 21/06/10 21.49, Jeff Moyer wrote:
> Hi,
> 
> In testing a workload that has a single fsync-ing process and another
> process that does a sequential buffered read, I was unable to tune CFQ
> to reach the throughput of deadline.  This patch, along with the previous
> one, brought CFQ in line with deadline when setting slice_idle to 0.
> 
> I'm not sure what the original reason for not allowing sync and async
> I/O to be dispatched together was.  If there is a workload I should be
> testing that shows the inherent problems of this, please point me at it
> and I will resume testing.  Until and unless that workload is identified,
> please consider applying this patch.

The problematic case is/was a normal SATA drive with a buffered
writer and an occasional reader. I'll have to double check my
mail tomorrow, but iirc the issue was that the occasional reader
would suffer great latencies since service times for that single
IO would be delayed at the drive side. It could perhaps just be
a bug in how we handle the slice idling on the read side when the
IO gets delayed initially.

So if my memory is correct, google for the fsync madness and
interactiveness thread that we had some months ago and which
caused a lot of tweaking. The commit adding this is
5ad531db6e0f3c3c985666e83d3c1c4d53acccf9 and was added back
in July last year. So it was around that time that the mails went
around.

-- 
Jens Axboe

--
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/