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

[Maxim Patlasov]

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)

Btw, CFQD_DISK_LOOKS_FAST() affects only idle/noidle behaviour for
seeky&deep queues. The question is which queues should be regarded as
'deep'. I tend to think that they experience deep queue quite often
and regularly. Then the chances to update looks_fast/looks_slow in
timely manner are high. At least "always ...  has < 4 requests queued"
is not the case for really 'deep' queues. As for "always only dispatch
< 4 requests", it's theoretically possible but should not happen often
for really 'deep' queues. And conversely, if a queue experienced deep
queue only once, is it good idea to regard it as 'deep' and grant
idle-window to it?

Thanks,
Maxim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/