diff options
author | Tejun Heo <tj@kernel.org> | 2012-03-05 13:15:21 -0800 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2012-03-06 21:27:24 +0100 |
commit | 9f13ef678efd977487fc0c2e489f17c9a8c67a3e (patch) | |
tree | e58a2dd153ad24b2ea173d5dfb575c507e1f7589 /tools/virtio | |
parent | e8989fae38d9831c72b20375a206a919ca468c52 (diff) | |
download | op-kernel-dev-9f13ef678efd977487fc0c2e489f17c9a8c67a3e.zip op-kernel-dev-9f13ef678efd977487fc0c2e489f17c9a8c67a3e.tar.gz |
blkcg: use double locking instead of RCU for blkg synchronization
blkgs are chained from both blkcgs and request_queues and thus
subjected to two locks - blkcg->lock and q->queue_lock. As both blkcg
and q can go away anytime, locking during removal is tricky. It's
currently solved by wrapping removal inside RCU, which makes the
synchronization complex. There are three locks to worry about - the
outer RCU, q lock and blkcg lock, and it leads to nasty subtle
complications like conditional synchronize_rcu() on queue exit paths.
For all other paths, blkcg lock is naturally nested inside q lock and
the only exception is blkcg removal path, which is a very cold path
and can be implemented as clumsy but conceptually-simple reverse
double lock dancing.
This patch updates blkg removal path such that blkgs are removed while
holding both q and blkcg locks, which is trivial for request queue
exit path - blkg_destroy_all(). The blkcg removal path,
blkiocg_pre_destroy(), implements reverse double lock dancing
essentially identical to ioc_release_fn().
This simplifies blkg locking - no half-dead blkgs to worry about. Now
unnecessary RCU annotations will be removed by the next patch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/virtio')
0 files changed, 0 insertions, 0 deletions