Subject: Re: Interactive responsiveness under heavy I/O load
To: None <tls@rek.tjls.com>
From: Steven M. Bellovin <smb@research.att.com>
List: netbsd-users
Date: 01/26/2004 20:38:16
In message <20040127005412.GA2672@panix.com>, 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