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

On Mon, Aug 21, 2006 at 03:28:40PM -0400, Steven M. Bellovin wrote:
> I don't have an explanation for your results (though I wonder if
> metadata-related reads are part of the explanation), but I have serious
> qualms about making processes sleep.  In the limiting case, that sets
> an upper bound on output rate, regardless of other demand.  Have you
> explored lowering scheduling priority instead?  That would allow other
> processes (which would generate read requests) to make more requeasts.

As one of the mentors for this project, I think changing scheduling
priority can/should be investigated after the SoC project completes.

I think there are a number of things to look into, like how to apply back=
=20
pressure, and different ways to estimate congestion/decide when we should=
=20
apply back pressure. I have a feeling we may well come up with a number of=
=20
different things to try.

The current scheme just stops a process, so we basically pump the breaks=20
on a writer. If a process stops writing (say it goes back to processing=20
data to write to another file), we stop hitting the breaks. With tweaking=
=20
the scheduling, we would be applying a more-gradual breaking. I'm not 100%=
=20
sure how to do this as I _think_ I want whatever we do to decay; if a=20
program shifts away from writing, I'd like it to move back to being=20
scheduled as if it had never written. I know the scheduler does this, I'm=
=20
just not sure how to map the dynamics from disk usage to those for CPU=20
usage.

i.e. how do we not turn the CPU scheduler into a monster if we do this.=20
:-)

Take care,

Bill

--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFE6hj3Wz+3JHUci9cRAlhpAJoCFdVBkHFw+f3/Bc0RvtbrGXtApwCgjZRC
vuxR9T+1tu4XHvoDIqOlWOw=
=DAUp
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--