DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:to:subject:date:user-agent:mime-version:content-disposition
         :message-id:content-type:content-transfer-encoding;
        b=OftG9i/TjKKsMyFL2hjnz6h4kR7BOIB+/havDQDUFME9Rx1MRNChAez5VMbqwEBCa4
         YF2gLSatnxh9WR5n1T5VKiVEj3pWRxO4Sir6DrbWXaoMlbms9jJVeSPSnan88HPaCo4q
         uQVThyhPDhteT3t4zR+flLbTfI7msGunF3efM=
From: Corrado Zoccolo <czoccolo@gmail.com>
To: "Linux-Kernel" <linux-kernel@vger.kernel.org>,
       Jens Axboe <jens.axboe@oracle.com>, Jeff Moyer <jmoyer@redhat.com>
Subject: [RFC PATCH 0/5] cfq-iosched: improve latency for no-idle queues
Date: Mon, 19 Oct 2009 22:20:52 +0200
User-Agent: KMail/1.11.4 (Linux/2.6.32cz; KDE/4.2.4; i686; ; )
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200910192220.53203.czoccolo@gmail.com>
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1660
Lines: 36

This patch series is intended to improve I/O latency, addressing an often 
neglected, important subset of workloads: the ones for which cfq currently 
prefers not to do any idling.

Those are the ones that would benefit most from having low latency, in fact 
they are any of:
* processes with large think times (e.g. interactive ones like file managers)
* seeky (e.g. programs faulting in their code at startup)
* or marked as no-idle from upper levels.

The patch series addresses this by:
* reducing queues' timeslice when many queues have pending I/O
* separating queues with different priorities and different characteristics in 
different service trees, each with an allocated time slice
* enable idling when switching between service trees, even for queues that 
would not have idling enabled otherwise.

This provides various benefits:
* service tree insertion code is simplified, since it doesn't need to cope with 
priorities any more.
* high priority no_idle queues are no longer penalized when competing with 
lower priority, idling queues
* seeky and no_idle queues have their fair share of disk time, without 
penalizing NCQ drives' performances, since they can all dispatch together, 
filling up the available NCQ slots.

On a non-NCQ capable drive, a workload of 4 random readers competing with 
sequential writer, the maximum latency experienced by readers decreased from > 
500ms to about 160ms.


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