Il giorno 31/mag/2014, alle ore 15:54, Tejun Heo <t...@kernel.org> ha scritto:
> On Thu, May 29, 2014 at 11:05:40AM +0200, Paolo Valente wrote: >> This patch introduces an heuristic that reduces latency when the >> I/O-request pool is saturated. This goal is achieved by disabling >> device idling, for non-weight-raised queues, when there are weight- >> raised queues with pending or in-flight requests. In fact, as >> explained in more detail in the comment to the function >> bfq_bfqq_must_not_expire(), this reduces the rate at which processes >> associated with non-weight-raised queues grab requests from the pool, >> thereby increasing the probability that processes associated with >> weight-raised queues get a request immediately (or at least soon) when >> they need one. > > Wouldn't it be more straight-forward to simply control how many > requests each queue consume by returning ELV_MQUEUE_NO? Arianna proposed me exactly this improvement about two months ago. The problem was that our TO-ADD list already contained several other improvements. So, to avoid waiting several more years before (re)submitting bfq, I decided that it would have been better to finally freeze the code for a while and pack it for submission. If you agree, investigating and implementing this improvement will be our next step immediately after, and if the current version of bfq gets merged in some form. Thanks, Paolo > Seeky ones do > benefit from larger number of requests in elevator but to only certain > number given the fifo timeout anyway and controlling that explicitly > would be a lot easier to anticipate the behavior of than playing > roulette with random request allocation failures. > > Thanks. > > -- > tejun -- Paolo Valente Algogroup Dipartimento di Fisica, Informatica e Matematica Via Campi, 213/B 41125 Modena - Italy homepage: http://algogroup.unimore.it/people/paolo/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
