Messages in this thread | | | Date | Tue, 6 Sep 2011 19:42:56 +0400 | Subject | Re: [PATCH 1/1] CFQ: fix handling 'deep' cfqq | From | 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
| |