new fifo I/O elevator that really does nothing at all

The noop elevator is still too fat for db transaction processing workload.
Since the db application already merged all blocks before sending it down,
the I/O presented to the elevator are actually not merge-able anymore. Since
I/O are also random, we don't want to sort them either.  However the noop
elevator is still doing a linear search on the entire list of requests in
the queue.  A noop elevator after all isn't really noop.

We are proposing a true no-op elevator algorithm, no merge, no nothing. Just
do first in and first out list management for the I/O request.  The best name
I can come up with is "FIFO".  I also piggy backed the code onto
noop-iosched.c.
I can easily pull those code into a separate file if people object.  Though, I
hope Jens is OK with it.


--- linux-2.6.11/drivers/block/noop-iosched.c.orig	2005-03-28 16:37:30.000000000
-0800
+++ linux-2.6.11/drivers/block/noop-iosched.c	2005-03-28 16:43:57.000000000
-0800
@@ -74,6 +74,21 @@ static struct request *elevator_noop_nex
 	return NULL;
 }

+static void elevator_fifo_add_request(request_queue_t *q, struct request *rq,
+				      int where)
+{
+	list_add_tail(&rq->queuelist, &q->queue_head);
+}
+
+static struct elevator_type elevator_fifo = {
+	.ops = {
+		.elevator_next_req_fn		= elevator_noop_next_request,
+		.elevator_add_req_fn		= elevator_fifo_add_request,
+	},
+	.elevator_name = "fifo",
+	.elevator_owner = THIS_MODULE,
+};
+
 static struct elevator_type elevator_noop = {
 	.ops = {
 		.elevator_merge_fn		= elevator_noop_merge,
@@ -87,12 +102,14 @@ static struct elevator_type elevator_noo

 static int __init noop_init(void)
 {
-	return elv_register(&elevator_noop);
+	return (elv_register(&elevator_noop) ||
+		elv_register(&elevator_fifo));
 }

 static void __exit noop_exit(void)
 {
 	elv_unregister(&elevator_noop);
+	elv_unregister(&elevator_fifo);
 }

 module_init(noop_init);


-
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/