From owner-freebsd-hackers  Fri Jun  6 05:26:13 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id FAA17180
          for hackers-outgoing; Fri, 6 Jun 1997 05:26:13 -0700 (PDT)
Received: from hda.hda.com (hda-bicnet.bicnet.net [207.198.1.121])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA17174
          for <hackers@freebsd.org>; Fri, 6 Jun 1997 05:26:09 -0700 (PDT)
Received: (from dufault@localhost)
	by hda.hda.com (8.8.5/8.8.5) id IAA18632;
	Fri, 6 Jun 1997 08:22:03 -0400 (EDT)
From: Peter Dufault <dufault@hda.com>
Message-Id: <199706061222.IAA18632@hda.hda.com>
Subject: Re: Extremely poor interactive response under heave SCSI load
In-Reply-To: <199706060811.KAA00771@ws6423.gud.siemens.at> from "Hr.Ladavac" at "Jun 6, 97 10:11:59 am"
To: lada@ws6303.gud.siemens.at (Hr.Ladavac)
Date: Fri, 6 Jun 1997 08:22:02 -0400 (EDT)
Cc: hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > 
> > 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