Re: IO Priorities

[Jeff Sipek <jeffpc@optonline.net>]

[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]

On Mon, Dec 13, 2004 at 03:38:10PM +0100, Jens Axboe wrote:
> On Mon, Dec 13 2004, Jeff Sipek wrote:
> > Hello all,
> > 	About a week ago, I said I would try to implement IO priorities.
> > I tried. I got the whole thing done, but there is one major problem - it
> 
> I did too, did you see my patch?

I did after I sent mine. I was reading it and I noticed:

"Disable TCQ in the hardware/driver by default. Can be changed (as
always) with the max_depth setting. If you do that, don't expect
fairness or priorities to work as well."

Would this cause my problem?

> > doesn't work the way it is supposed to. For example, I wrote a little
> > shell script that calls:
> > 
> > time dd if=/dev/zero of=dump bs=4096 count=200000
> > 
> > It calls it twice, once as the highest priority (0) and once as the
> > lowest priority (39). The only difference (besides the output file) is
> > the io priority. Nice values are _not_ connected with io prio (at least
> > not yet.) The only thing that the io_prio affects is the coefficient in
> > front of the cfq time slice length (see patch). The interesting thing
> > that happens is that sometimes the lower priority process finishes before
> > the higher priority one - even though the time slices are WAY way different
> > in size (1ms and 223ms). Con Kolivas told me that he experienced the same
> > odd behaviour when he implemented io priorities on top of deadline.
> 
> Well, for this specific case, I'd suggest you check out how much of the
> write out actually happens in context of that process. Often you end up
> with pdflush(es) doing the process dirty work, and the io priorities
> aren't inherited across that boundary.

Hmm....will do.

> > -static int cfq_slice_sync = HZ / 10;
> > -static int cfq_slice_async = HZ / 25;
> > +static int cfq_slice_sync = HZ / 1000;
> > +static int cfq_slice_async = HZ / 1000;
> >  static int cfq_slice_async_rq = 16;
> > -static int cfq_slice_idle = HZ / 249;
> > +static int cfq_slice_idle = HZ / 1000;
> 
> You need to be careful, on archs with HZ == 100 you just set every time
> slice to 0.

Yes, I was trying to get to work on my box first.

> > +/* the slice scaling factors */
> > +static int cfq_prio_scale[] = {223, 194, 169, 147, 128,		/* 0..4 */
> > +			       111,  97,  84,  73,  64,		/* 5..9 */
> > +			        56,  49,  42,  36,  32,		/* 10..14 */
> > +			        28,  24,  21,  18,  16,		/* 15..19 */
> > +			        14,  12,  11,   9,   8,		/* 20..24 */
> > +			         7,   6,   5,   5,   4,		/* 25..29 */
> > +			         3,   3,   2,   2,   2,		/* 30..34 */
> > +			         1,   1,   1,   1,   1};	/* 35..39 */
> 
> I think it's pointless to scale it so fine grained (see my earlier
> postings).

I guess 40 priorities is a little too much. Now that I am thinking about
it more, 40 levels is way too much. I'll change it later.

> Additionally, you don't do anything with the priorities internally.

Sure I do, I multiply the slice by cfq_prio_scale[ioprio]. It did seem
too simple. :-) Looking at your code right now, I kind of see some code
that should have been in my implementation as well. Back to coding...
:-)

Jeff.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]