linux-kernel - Re: [PATCH/RFC 0/4] cfq: implement merging and breaking up of 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: <4e5e476b0910241308s4a14fb69jbc6f8d35eb0ab78@mail.gmail.com>
Date:	Sat, 24 Oct 2009 22:08:48 +0200
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	jens.axboe@...cle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC 0/4] cfq: implement merging and breaking up of 
	cfq_queues

Hi Jeff,
this series looks good.
I like in particular the fact that you move seekiness detection in the cfqq.
This can help with processes that issue sequential reads and seeky
writes, or vice versa.
Probably, also the think time could be made per-cfqq, so that the
decision whether we should idle for a given cfqq is more precise.

On Fri, Oct 23, 2009 at 11:14 PM, Jeff Moyer <jmoyer@...hat.com> wrote:
> Hi,
>
> This is a follow-up patch to the original close cooperator support for
> CFQ.  The problem is that some programs (NFSd, dump(8), iscsi target
> mode driver, qemu) interleave sequential I/Os between multiple threads
> or processes.  The result is that there are large delays due to CFQ's
> idling logic that leads to very low throughput.

You identified the problem in the idling logic, that reduces the
throughput in this particular scenario, in which various threads or
processes issue (in random order) the I/O requests with different I/O
contexts on behalf of a single entity.
In this case, any idling between those threads is detrimental.
Ideally, such cases should be already spotted, since think time should
be high for such processes, so I wonder if this indicates a problem in
the current think time logic.
Can you send me your read-test, so I can investigate it?

Thanks,
Corrado
--
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/