Re: [PATCH 03/20] blkio: Introduce the notion of weights

[Jeff Moyer]

Vivek Goyal <vgoyal@xxxxxxxxxx> writes:

> On Wed, Nov 04, 2009 at 10:06:16AM -0500, Jeff Moyer wrote:
>> Vivek Goyal <vgoyal@xxxxxxxxxx> writes:
>> 
>> > o Introduce the notion of weights. Priorities are mapped to weights internally.
>> >   These weights will be useful once IO groups are introduced and group's share
>> >   will be decided by the group weight.
>> 
>> I'm sorry, but I need more background to review this patch.  Where do
>> the min and max come from?  Why do you scale 7-0 from 200-900?  How does
>> this map to what was there before (exactly, approximately)?
>> 
>
> Well, So far we only have the notion of iopriority for the process and
> based on that we determine time slice length.
>
> Soon we will throw cfq groups also in the mix. Because cpu IO controller
> is weight driven, people have shown preference that group's share should
> be decided based on its weight and not introduce the notion of ioprio for
> groups.

I certainly agree with that.

> Hence, to begin with I wanted to limit the range of weights allowed because
> wider range opens up lot of interesting corner cases. That's why limited
> minimum weight to 100. So at max user can expect the 1000/100=10 times service
> differentiation between highest and lower weight groups. If folks need more
> than that, we can look into it once things stablize.
>
> Priority and weights follow reverse order. Higher priority means low
> weight and vice-versa.
>
> Currently we support 8 priority levels and prio "4" is the middle point.
> Anything higher than prio 4 gets 20% less slice as compared to prio 4 and
> priorities lower than 4, get 20% higher slice of prio 4 (20% higher/lower
> for each priority level).
>
> For weight range 100 - 1000, 500 can be considered as mid point. Now this
> is how priority mapping looks like.
>
> 	100 200 300 400 500 600 700 800 900 1000  (Weights) 
> 	     7   6   5   4   3   2  1   0         (io prio).
>
> Once priorities are converted to weights, we are able to retain the notion
> of 20% difference between prio levels by choosing 500 as the mid point and
> mapping prio 0-7 to weights 900-200, hence this mapping. 

I see.  So when using the old ioprio mechanism, we get a smaller range
of possible values than with the cgroup configuration.

> I am all ears if you have any suggestions on how this ca be handled
> better.

I think that's a fine way to handle it.  I just needed to be spoon-fed.
It would be nice if you included a write-up of how service is
differentiated in your documentation patch.  In other words, from the
point of view of the sysadmin, how does he use the thing?  Simple math
would likely help, too.

Cheers,
Jeff
--
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/