`Vivek Goyal <vgoyal@redhat.com> writes:> On Wed, Nov 04, 2009 at 10:06:16AM -0500, Jeff Moyer wrote:>> Vivek Goyal <vgoyal@redhat.com> 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 rangeof 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 isdifferentiated in your documentation patch.  In other words, from thepoint of view of the sysadmin, how does he use the thing?  Simple mathwould likely help, too.Cheers,Jeff`