The general question has either appeared on this list or tech-kern
already with specific references to X and web browsers too!!!! The
problem as it seemed to me was that it is not a cpu or disk scheduling
policy (although improvements could help the situation).

 --- "Steven M. Bellovin" <smb@research.att.com> wrote: > 
> For what it's worth, I'm *extremely* unhappy with the disk buffering 
> strategy on NetBSD.  Last night, I was dumping my laptop's (1.6) disk
> 
> to a drive on my desktop.  The desktop (-current, 1.6K) was
> completely
> unusable during that time -- the disk was so busy that the machine 
> seemed to be unable to page in Mozilla.  All the desktop was running 
> for this backup was 'cat', which isn't that bloated (yet...).  It was
> 
> writing to one file, so it's not a vnode cache issue.

Here is the problem: Mozilla should not have been paged out if it was
in active use. The UBC system doesn't understand the concept of
"working set" or even an approximation, so it will readily gooble
memory and cause Mozilla, X, and many other large processes to page
out. I think that there needs to be a way to effectively prioritize
pages in memory so better choices are made for replacement. When these
applications eventually execute (like to update the display) and get
paged back in, of course the effective memory access time gets
thousands of times slower and which is why something that is not disk
intensive (like screen repainting) takes longer. Using SCSI, better
schedulers for cpu/disk, and softdep will probably help, but any
application which is forced to cause disk-related page faults to
execute will ALWAYS be slower than one that has its active pages
resident in memory.

I think the reason it is less severe in 1.5 (which has *again* been
mentioned as it was in the first discussion, although the significance
was denied then and will probably be again) is that 1.5 uses a FIXED
size, DEDICATED file/buffer cache: applications never compete with it
for memory, so lots of file I/O will not cause them to page out (it
prints out the size at boot time, although 1.6 and current kernels also
seem do this).

> 
> I'm running with default vm.* sysctls, and softdep on.  Here's the 
> drive info:
> 
> # atactl wd0 identify
> Model: IBM-DTLA-307075, Rev: TXAOA50C, Serial #:          YSDYSFL9921
> Device type: ATA, fixed
> Cylinders: 16383, heads: 16, sec/track: 63, total sectors: 150136560
> Device supports command queue depth of 15
> Device capabilities:
>         ATA standby timer values
>         IORDY operation
>         IORDY disabling
> Device supports following standards:
> ATA-2 ATA-3 ATA-4 
> Command set support:
>         NOP command
>         READ BUFFER command
>         WRITE BUFFER command
>         Host Protected Area feature set
>         release interrupt
>         look-ahead
>         write cache
>         Power Management feature set
>         Security Mode feature set
>         SMART feature set
>         Advanced Power Management feature set
>         READ/WRITE DMA QUEUED commands
> Command sets/features enabled:
>         look-ahead
>         write cache
> 
> The CPU is a ~750 Mhz Athlon with a VIA chipset and 256M of RAM.  And
> 
> I'm extremely unhappy with interactive performance these days.  (It
> was 
> embarrassing, too -- I was trying to order something on the Web for
> my 
> son last night, and I had to suspend the backup process to do so. 
> He's 
> always hearing from me how much better Unix is than Windows at 
> timesharing...)

Windows is too ready to swap out processes, even when memory is free,
so it would probably be worse if you were using something like W2K
(although it may be possible to tune it not to do this) to do the
equivalent.

> 
> Now -- going back 25 years, Unix has never been at its best in the
> face 
> of a heavy I/O load, because of the lack of a priority feedback
> scheme 
> in the disk scheduler.  A process that uses too much CPU is penalized
> 
> relative to other processes; the same is not true of I/O.  Even if it
> 
> were, that wouldn't necessarily help, because stuff is being thrown
> out 
> of the buffer cache far too rapidly, causing a lot of unnecessary I/O
> 
> bring things back in.

I/O scheduling will help I/O bound processes definately, but X or
Mozilla are not in this category. Heavy disk activity should have
little or no effect on them. I don't think that one or more processes
waiting for disk I/O has much of a penalty on other processes's
performance on NetBSD. Try something with a floppy disk: generate lots
and lots of I/O for the disk from multiple processes: I would bet that
because only 1.4 MB of data can ever be outstanding for the disk, it
won't ever cause similar problems despite being much slower (yes its
primitive, but I can't think of anything better).

However, if the system is not doing any paging at all (and you watch
for this throughout the entire period of heavy disk I/O), then I guess
I am completely wrong! The definitive answer will come from UBC
developer(s) like Chuck Silvers.

> 
> 
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb (me)
> 		http://www.wilyhacker.com (2nd edition of "Firewalls" book)
> 
>  

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca