lkml.org 
[lkml]   [2013]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 07/31] blk-throttle: removed deferred config application mechanism
On Wed, May 01, 2013 at 05:39:25PM -0700, Tejun Heo wrote:

[..]
> @@ -1023,9 +975,27 @@ static int tg_set_conf(struct cgroup *cgrp, struct cftype *cft, const char *buf,
> else
> *(unsigned int *)((void *)tg + cft->private) = ctx.v;
>
> - /* XXX: we don't need the following deferred processing */
> - xchg(&tg->limits_changed, true);
> - xchg(&td->limits_changed, true);
> + throtl_log_tg(td, tg, "limit change rbps=%llu wbps=%llu riops=%u wiops=%u",
> + tg->bps[READ], tg->bps[WRITE],
> + tg->iops[READ], tg->iops[WRITE]);
> +
> + /*
> + * We're already holding queue_lock and know @tg is valid. Let's
> + * apply the new config directly.
> + *
> + * Restart the slices for both READ and WRITES. It might happen
> + * that a group's limit are dropped suddenly and we don't want to
> + * account recently dispatched IO with new low rate.
> + */
> + throtl_start_new_slice(td, tg, 0);
> + throtl_start_new_slice(td, tg, 1);
> +
> + if (throtl_tg_on_rr(tg)) {
> + tg_update_disptime(td, tg);
> + throtl_schedule_next_dispatch(td);
> + }
> +
> + /* kick dispatch in case disptime got shortened */
> throtl_schedule_delayed_work(td, 0);

Hi Tejun,

Do we need above throtl_schedule_delayed_work() now?
throtl_schedule_next_dispatch() should take care of it. And if group
is not on service tree at the time of limit change, then anyway, we don't
have to schedule any work.

Thanks
Vivek


\
 
 \ /
  Last update: 2013-05-02 17:01    [W:0.230 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site