linux-kernel - Re: [PATCH 1/1] CFQ: fix handling 'deep' cfqq

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]

Date:	Fri, 9 Sep 2011 12:43:59 +0800
From:	Shaohua Li <shli@...nel.org>
To:	Maxim Patlasov <maxim.patlasov@...il.com>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] CFQ: fix handling 'deep' cfqq

2011/9/6 Maxim Patlasov <maxim.patlasov@...il.com>:
> Shaohua,
>
>>> If the queue does dispatch > 4 requests in one jiffy, only
>>> cfq_disk_looks_fast is updated - that's right. But if the queue
>>> dispatches first 4 requests in *more* than one jiffy,
>>> cfq_disk_looks_slow is updated.
>> So the case is in first round, the queue dispatch > 4 requests in one jiffy,
>> looks_fast gets updated. Later, if the queue always only dispatch < 4 requests
>> or has < 4 requests queued, no looks_fast/looks_slow gets updated till
>> 10*HZ later.
>> CFQD_DISK_LOOKS_FAST() always returns true in the period. is this sane?
>
> Thanks a lot for feedback. I agree, a single accidental event should
> not affect the whole system for so long. What do you think about
> making positive decision only if some amount of events were gathered
> recently:
>
> #define CFQD_DISK_LOOKS_FAST(cfqd)                                  \
>        (cfqd->cfq_disk_looks_fast > cfqd->cfq_disk_looks_slow &&   \
>         cfqd->cfq_disk_looks_fast + cfqd->cfq_disk_looks_slow > 10)
I'm sorry a little later to reply.
that's better, but I'm still unsatisfied with the detection if a device is fast.

So the key problem here is how to detect if a device is fast. Doing
the detection
in the dispatch stage always can't give us correct result. A fast device really
should be requests can be finished in short time. So I have something attached.
In my environment, a hard disk is detected slow and a ssd is detected fast, but
I haven't run any benchmark so far. How do you think about it?

Thanks,
Shaohua

View attachment "cfq-fast-device-detech.patch" of type "text/x-patch" (3032 bytes)