Subject: Re: Throttling IO Requests in NetBSD via Congestion Control
To: Steven M. Bellovin <>
From: Bill Studenmund <>
List: tech-kern
Date: 08/21/2006 13:35:03
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=
pressure, and different ways to estimate congestion/decide when we should=
apply back pressure. I have a feeling we may well come up with a number of=
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=
the scheduling, we would be applying a more-gradual breaking. I'm not 100%=
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=
just not sure how to map the dynamics from disk usage to those for CPU=20

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

Take care,


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

Version: GnuPG v1.4.3 (NetBSD)