Re: [PATCH 07/31] blk-throttle: removed deferred config applicationmechanism

[Vivek Goyal]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/