Re: Interactive responsiveness under heavy I/O load

In message <[email protected]>, Thor Lancelot Simon writes:
>On Mon, Jan 26, 2004 at 12:28:57PM -0500, Steven M. Bellovin wrote:
>> 
>> Thor, I find -current to be almost unusable for interactive work when 
>> there's something I/O-intensive running at the same time.  I have
>> NEW_BUFQ_STRATEGY enabled, as best I can tell.  Here are my vm. sysctl 
>
>What kind of disk do you have?  The option for NEW_BUFQ_STRATEGY is
>stupidly implemented -- it's turned on or off down in the disk driver.
>If you happen to be using an 'ld', for instance, there's no #ifdef in
>ld.c, so the option does nothing.  ("Don't get me started...")
>
>Are you using softdep?  When Paul removed the fixed limit on the number
>of entries in the metadata cache, he accidentally upset the entire house
>of cards on which the stability of the I/O system rested, in the softdep
>case at least.  The _only_ thing keeping softdep from flooding the queues
>with more I/O per second than they could actually handle was that our old
>buffer cache implementation imposed an extremely low limit on the number
>of pending directory operations at any given time, causing writers (well,
>directory-operators, really) to block and preventing them from pouring
>as much I/O into the pipe as softdep would let them in one second.
>
>I have a patch, as I said, to spread the I/O out by playing with the
>use of "dirdelay".  I can send it to you to try out if you like.
>

Unfortunately, I can't tell you right now.  Or rather, I know I'm using 
ordinary IDE disks, via the wd driver; I don't think I have softdep on, 
but I can't say for sure because my -current machine is having POST 
problems and won't boot right now.  (Thinking I had a work-around, I 
stupidly upgraded to 1.6ZI just now.  I did get it to boot, once, long 
enough to install userspace, but I couldn't get it to reboot.  Sigh.)


		--Steve Bellovin, http://www.research.att.com/~smb