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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
