diff options
author | Vivek Goyal <vgoyal@redhat.com> | 2010-10-01 08:49:49 -0400 |
---|---|---|
committer | Jens Axboe <jaxboe@fusionio.com> | 2010-10-01 08:49:49 -0400 |
commit | fe0714377ee2ca161bf2afb7773e22f15f1786d4 (patch) | |
tree | 09f5e8686d741d012333c92251b8cc66793ef916 /drivers/video/xen-fbfront.c | |
parent | 02977e4af7ed3b478c505e50491ffdf3e1314cf4 (diff) |
blkio: Recalculate the throttled bio dispatch time upon throttle limit change
o Currently any cgroup throttle limit changes are processed asynchronousy and
the change does not take affect till a new bio is dispatched from same group.
o It might happen that a user sets a redicuously low limit on throttling.
Say 1 bytes per second on reads. In such cases simple operations like mount
a disk can wait for a very long time.
o Once bio is throttled, there is no easy way to come out of that wait even if
user increases the read limit later.
o This patch fixes it. Now if a user changes the cgroup limits, we recalculate
the bio dispatch time according to new limits.
o Can't take queueu lock under blkcg_lock, hence after the change I wake
up the dispatch thread again which recalculates the time. So there are some
variables being synchronized across two threads without lock and I had to
make use of barriers. Hoping I have used barriers correctly. Any review of
memory barrier code especially will help.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Diffstat (limited to 'drivers/video/xen-fbfront.c')
0 files changed, 0 insertions, 0 deletions