kernel.git/include/linux/iocontext.h, branch linux-2.6.32.y

block: Fix io_context leak after failure of clone with CLONE_IO

2012-10-07T21:37:22Z

commit b69f2292063d2caf37ca9aec7d63ded203701bf3 upstream With CLONE_IO, parent's io_context->nr_tasks is incremented, but never decremented whenever copy_process() fails afterwards, which prevents exit_io_context() from calling IO schedulers exit functions. Give a task_struct to exit_io_context(), and call exit_io_context() instead of put_io_context() in copy_process() cleanup path. Signed-off-by: Louis Rilling Signed-off-by: Jens Axboe Signed-off-by: Willy Tarreau

cfq: calculate the seek_mean per cfq_queue not per cfq_io_context

2011-11-07T20:32:38Z

commit b2c18e1e08a5a9663094d57bb4be2f02226ee61c upstream. async cfq_queue's are already shared between processes within the same priority, and forthcoming patches will change the mapping of cic to sync cfq_queue from 1:1 to 1:N. So, calculate the seekiness of a process based on the cfq_queue instead of the cfq_io_context. Signed-off-by: Jeff Moyer Signed-off-by: Jens Axboe Signed-off-by: Suresh Jayaraman Signed-off-by: Greg Kroah-Hartman

io context: fix ref counting

2009-07-31T06:55:48Z

Commit d9c7d394a8ebacb60097b192939ae9f15235225e ("block: prevent possible io_context->refcount overflow") mistakenly changed atomic_inc(&ioc->nr_tasks) to atomic_long_inc(&ioc->refcount). Signed-off-by: Li Zefan Acked-by: Nikanth Karthikesan Signed-off-by: Jens Axboe

block: prevent possible io_context->refcount overflow

2009-06-10T21:07:15Z

Currently io_context has an atomic_t(32-bit) as refcount. In the case of cfq, for each device against whcih a task does I/O, a reference to the io_context would be taken. And when there are multiple process sharing io_contexts(CLONE_IO) would also have a reference to the same io_context. Theoretically the possible maximum number of processes sharing the same io_context + the number of disks/cfq_data referring to the same io_context can overflow the 32-bit counter on a very high-end machine. Even though it is an improbable case, let us make it atomic_long_t. Signed-off-by: Nikanth Karthikesan Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe

block: blkdev.h cleanup, move iocontext stuff to iocontext.h

2008-07-03T11:21:14Z

Signed-off-by: Jens Axboe

io context: increment task attachment count in ioc_task_link()

2008-04-15T07:25:33Z

Thanks to Nikanth Karthikesan for reporting this. Signed-off-by: Jens Axboe

cfq-iosched: fix rcu freeing of cfq io contexts

2008-04-02T13:42:20Z

SLAB_DESTROY_BY_RCU is not a direct substitute for normal call_rcu() freeing, since it'll page freeing but NOT object freeing. So change cfq to do the freeing on its own. Signed-off-by: Fabio Checconi Acked-by: Paul E. McKenney Signed-off-by: Jens Axboe

cfq-iosched: add hlist for browsing parallel to the radix tree

2008-02-19T09:04:00Z

It's cumbersome to browse a radix tree from start to finish, especially since we modify keys when a process exits. So add a hlist for the single purpose of browsing over all known cfq_io_contexts, used for exit, io prio change, etc. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=9948 Signed-off-by: Jens Axboe

block: cfq: make the io contect sharing lockless

2008-01-28T09:50:33Z

The io context sharing introduced a per-ioc spinlock, that would protect the cfq io context lookup. That is a regression from the original, since we never needed any locking there because the ioc/cic were process private. The cic lookup is changed from an rbtree construct to a radix tree, which we can then use RCU to make the reader side lockless. That is the performance critical path, modifying the radix tree is only done on process creation (when that process first does IO, actually) and on process exit (if that process has done IO). As it so happens, radix trees are also much faster for this type of lookup where the key is a pointer. It's a very sparse tree. Signed-off-by: Jens Axboe

io context sharing: preliminary support

2008-01-28T09:50:31Z

Detach task state from ioc, instead keep track of how many processes are accessing the ioc. Signed-off-by: Jens Axboe