Subject: Re: UBC, interactive performance, etc
To: None <tls@rek.tjls.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 04/04/2001 14:46:44
>I think the right way to address your concern -- though it's nontrivial --
>is to teach the I/O subsystem to attempt to maintain a constant rate of
>I/O.  Then we can flow-control the buffer cache so that we do not accept
>writes we can't clear in some known amount of time (let them block).

Sounds right to me. Imagine a workload which generates an
arbitrarily-high sustained bandwidth of write requests. (Anything
which generates writes to a device faster than the long-term write
rate of hte device will do.)

With a dedicated buffer cache, that app gets to use up to the entire
buffer-cache. With UBC and no rate control, the app can easily dirty
all of memory -- which adversely affects all other apps.
But in spite of dirtying all that memory, it wont get much (if any)
more throughput than the previous case.


Anyone know how well other VM systems -- e.g., FreeBSD's -- stand up
to that kind of punishment?  Can we adopt some of their heuristics?

>This is similar to something LFS needs to do, actually.  What do you think?

Maybe not just LFS.