Re: IO Priorities

[Jeff Sipek]

--Qxx1br4bt0+wmkIi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
>=20
> 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:
> >=20
> > time dd if=3D/dev/zero of=3Ddump bs=3D4096 count=3D200000
> >=20
> > 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 befo=
re
> > the higher priority one - even though the time slices are WAY way diffe=
rent
> > in size (1ms and 223ms). Con Kolivas told me that he experienced the sa=
me
> > odd behaviour when he implemented io priorities on top of deadline.
>=20
> 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 =3D HZ / 10;
> > -static int cfq_slice_async =3D HZ / 25;
> > +static int cfq_slice_sync =3D HZ / 1000;
> > +static int cfq_slice_async =3D HZ / 1000;
> >  static int cfq_slice_async_rq =3D 16;
> > -static int cfq_slice_idle =3D HZ / 249;
> > +static int cfq_slice_idle =3D HZ / 1000;
>=20
> You need to be careful, on archs with HZ =3D=3D 100 you just set every ti=
me
> slice to 0.

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

> > +/* the slice scaling factors */
> > +static int cfq_prio_scale[] =3D {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 */
>=20
> 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.

--Qxx1br4bt0+wmkIi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBvcatwFP0+seVj/4RAr/IAJ0QzRo3JZVEOKYG0FbnXedE+vmHpgCgpzZC
1wsH8DngzUa/FFMcnjRzQjM=
=5XSm
-----END PGP SIGNATURE-----

--Qxx1br4bt0+wmkIi--
-
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/