Date: Fri, 6 Jun 1997 08:22:02 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: lada@ws6303.gud.siemens.at (Hr.Ladavac) Cc: hackers@freebsd.org Subject: Re: Extremely poor interactive response under heave SCSI load Message-ID: <199706061222.IAA18632@hda.hda.com> In-Reply-To: <199706060811.KAA00771@ws6423.gud.siemens.at> from "Hr.Ladavac" at "Jun 6, 97 10:11:59 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > There has to be some solution, forcing the scsi command queue to search for > > alternate commands every so often or something.. It just sucks :) > > You're telling it :) > > The problem is extremely easy to reproduce if you have one of these > PD drives and use them for backups. > > You will need a FFS on the PD media so that you can mount it. Then write to > the PD. Since this operation is extremely slow, a nice amount of backlogged > blocks will be made in cache--in fact, 16MB of RAM is more than enough-- > especially if you do a dump to the PD. Ramble on: The first problem mentioned involved only user processes and raw I/O. One solution is scheduling the I/O based on process priority - take rtprio first, normal priority next, and idleprio last with some gradation at each level resulting in 32 levels, then schedule I/O based on priority and round-robin across equal priority. Now run the offending process with a reduced priority. Of course the problem is simply-complicated by the fact that first you have to get in line to get the resources in order (queue slots in the target device, then host adapter transactions), and complicated-complicated by the desire to tie this into the sequencing code for devices with small buffers that keep reconnecting for the next chunk of a transfer so you can schedule the bus utilization. Since wakeup is decided based on priority I expect there will be an improvement in the tar example by niceing it. This new example ties in to the buffer cache, the amount of outstanding I/O, the memory you're tieing up etc. and I don't know how it plays. -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706061222.IAA18632>