Subject: Re: I/O priorities
To: None <tech-kern@NetBSD.ORG>
From: Gary Thorpe <gat7634@hotmail.com>
List: tech-kern
Date: 06/21/2002 16:39:35
>From: woods@weird.com (Greg A. Woods)
>Reply-To: tech-kern@NetBSD.ORG (NetBSD Kernel Technical Discussion List)
>To: tech-kern@netbsd.org
>Subject: Re: I/O priorities
>Date: Fri, 21 Jun 2002 16:29:15 -0400 (EDT)
>
>[ On Friday, June 21, 2002 at 13:53:33 (-0400), Gary Thorpe wrote: ]
> > Subject: Re: I/O priorities
> >
> > The original poster said the behaviour was only noticeable in 1.6, which 
>has
> > UBC and not in 1.5.2 which does not. Since BOTH of these releases use 
>the
> > SAME disk scheduling algorithm (yes?), the problem is not with CSCAN vs.
> > elevator vs. whatever disk scheduling algorithm. Major difference: 1.5.2 
>has
> > a FIXED size buffer and a FIXED sized cache while UBC has a variable 
>size
> > combined scheme (yes?). Perhaps in 1.5.2 the FIXED sizes provide some
> > predefined means of limiting I/O requests, while in 1.6 the variable 
>size
> > has lead to the overlooking of a new mechanism for limiting I/O requests
> > (which must be determined dynamically at run time depending on load 
>etc.).
>
>I think that's a fairly accurate analysis -- the only thing missing
>being that the poster had adjusted various cache sizes and min/max
>parameters from their default, but I don't think that detracts from the
>fact that it's now easier to batch up enough I/O requests such that some
>interactive response might suffer should the system be generally starved
>for resources.
>
>--
>								Greg A. Woods

I disagree. It would make perfect sense if the person were experiencing 
'skips' while playing mp3's or some type of multimedia file which would be 
I/O dependant (I/O scheduling *would* be useful here and it probably should 
be done for things like this). However, the problem was with Xterm and not 
just any Xterm: it was an active process and yet it was causing page faults?

If the problem was that Xterm slowed up because of page faulting, despite 
the fact that it is a currently active process, doesn't this imply that UBC 
is grabbing pages from active processes for buffering I/O leading to 
excessive page faults and even more I/O? If the disk is busy, normally Xterm 
would not care as it does not read/write files regularly (it at all?).

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx