11 Jun, 2009
1 commit
-
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
07 May, 2008
1 commit
-
put_io_context() drops the RCU read lock before calling into cfq_dtor(),
however we need to hold off freeing there before grabbing and
dereferencing the first object on the list.So extend the rcu_read_lock() scope to cover the calling of cfq_dtor(),
and optimize cfq_free_io_context() to use a new variant for
call_for_each_cic() that assumes the RCU read lock is already held.Hit in the wild by Alexey Dobriyan
Signed-off-by: Jens Axboe
19 Feb, 2008
2 commits
-
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
-
blk_ioc_init() can become static.
Signed-off-by: Adrian Bunk
Signed-off-by: Jens Axboe
01 Feb, 2008
1 commit
-
It blindly copies everything in the io_context, including the lock.
That doesn't work so well for either lock ordering or lockdep.There seems zero point in swapping io contexts on a request to request
merge, so the best point of action is to just remove it.Signed-off-by: Jens Axboe
30 Jan, 2008
1 commit
-
Adds files for barrier handling, rq execution, io context handling,
mapping data to requests, and queue settings.Signed-off-by: Jens Axboe