lkml.org 
[lkml]   [2011]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 1/1] CFQ: fix handling 'deep' cfqq
From
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


\
 
 \ /
  Last update: 2011-09-06 17:45    [W:0.083 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site