All,
      Looks like finally the problem has been nailed down:

The skewed results are due to non-availability of pages for the reader
process. As a matter of fact the results are all reproducible.

When the number of free pages in the system are sufficiently high (i.e
the page daemon need not run frequently), then using CCA **increases** the
transactions per second for the reader when the writer is put to
sleep. However, presence of one writer does not cause much impact on
the reader .. At
least 5 writers were required in my system (without causing the free
page pool to go down so as to trigger the page daemon).

However, if there appears a writer(s) operating on a huge file size (>1mb),
then all the free pages in the UVM are consumed by the **writer process**
and the reader is starved due to non-availability of pages. Actually
even though the CCA works, but its benefits are not easily observable.

So, I think we need to partition the UVM page allocation between
reader and writer processes. Thus if P is the total number of pages,
P_W pages are allocated to writer processes while P_R are allocated to
reader process. All writers compete for P_W pages while all reader
competes for P_R processes..

In a nutshell, the proposal is for a admission control mechanism in
the uvm for writer processes along with the uvm_cca algorithm.

Please let me know your inputs,

Thanks,
Sumantra

On 8/28/06, TlorD <tld@tld.digitalcurse.com> wrote:
> Bill Studenmund wrote:
> > On Mon, Aug 21, 2006 at 04:46:59PM -0400, Kurt J. Lidl wrote:
> >> On Mon, Aug 21, 2006 at 01:35:03PM -0700, Bill Studenmund wrote:
> >> As for the slowdown that is seen, you might just be forcing more
> >> head I/O on the platter, which will quickly dominate any other sources
> >> of slowness.
> >
> > I don't think so. I can certainly see extra seek action contributing to
> > reads not catching up as much as writes are restrained (i.e. I could see
> > this contributing to a 20% slowdown in writes turning into less than a 20%
> > increase in reads). But we're seeing fewer reads overall.
>
> Just a random thought: what if the induced sleep is interfering with the
> I/O scheduler/disk buffers, thus causing more seeks?
> Let me try to clarify: good reads and writes are big, sequential ones,
> sent one after the other to the disk which then moves the head as little
> as possible. If, by adding sleeps, writes are sent few per batch, they
> can't be coalesced well and will thus be transformed into bad (small)
> writes, which would skyrocket the seek number thus lowering the read
> rate. I think.
>
> Greetings,
>         TLD
>