summaryrefslogtreecommitdiff
path: root/include/linux/blkdev.h
diff options
context:
space:
mode:
authorJens Axboe <axboe@suse.de>2005-01-12 17:00:45 -0800
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-01-12 17:00:45 -0800
commit80ce63d3a9a3ca3bcd0232caeb3bfb127af5ad35 (patch)
treecb08dce7e0495e07c979f8481c8d05edd5eadc9f /include/linux/blkdev.h
parent6ddb58de00dfff82ccd08d9d14ab3c615ce52456 (diff)
[PATCH] possible rq starvation on oom
I stumbled across this the other day. The block layer only uses a single memory pool for request allocation, so it's very possible for eg writes to have allocated them all at any point in time. If that is the case and the machine is low on memory, a reader attempting to allocate a request and failing in blk_alloc_request() can get stuck for a long time since no one is there to wake it up. The solution is either to add the extra mempool so both reads and writes have one, or attempt to handle the situation. I chose the latter, to save the extra memory required for the additional mempool with BLKDEV_MIN_RQ statically allocated requests per-queue. If a read allocation fails and we have no readers in flight for this queue, mark us rq-starved so that the next write being freed will wake up the sleeping reader(s). Same situation would happen for writes as well of course, it's just a lot more unlikely. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include/linux/blkdev.h')
-rw-r--r--include/linux/blkdev.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1b7dc44bf3c1..5615a3c9e410 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -95,6 +95,7 @@ void swap_io_context(struct io_context **ioc1, struct io_context **ioc2);
struct request_list {
int count[2];
+ int starved[2];
mempool_t *rq_pool;
wait_queue_head_t wait[2];
wait_queue_head_t drain;