Date: Fri, 06 Jun 1997 14:57:00 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Peter Dufault <dufault@hda.com> Cc: lada@ws6303.gud.siemens.at (Hr.Ladavac), hackers@FreeBSD.ORG Subject: Re: Extremely poor interactive response under heave SCSI load Message-ID: <199706061958.NAA00853@pluto.plutotech.com> In-Reply-To: Your message of "Fri, 06 Jun 1997 08:22:02 EDT." <199706061222.IAA18632@hda.hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. The problem with this is a size issue. The CAM architecture works like this: controller resource queue | device1 - device2 - device3 .... (heap based priority queue) | periph driver1 - periph driver2 - (heap base priority queue) So, a peripherial driver X asks to be scheduled on device Y at priority Z. This causes the device to be "heaped up" to whatever it's new priority is. When an opening is availible on the controller, the first device is run and it in turn pulls the highest priority peripheral driver and askes it to do 1 transaction worth of work. Since there is a relatively constant number of devices and peripheral instances, heaps work great for this. I even use a heap in each device instance to requeue retried transactions based on priority and a generation number so that "replays" occur correctly and automatically when an error occurs that causes a whole bunch of transactions to be requeued. This works great for things like a "RAID" peripheral driver sharing a device with normal system I/O going through the normal disk peripheral driver each possibly running at different priorities. It also ensures that controller resources are doled out fairly instead of allowing a single device to monopolize the controller. It also ensures that whatever priority scheme is determined by a peripheral driver, that those priorities are in effect even in the case of errors and retries. It doesn't solve the "sluggish interractive response" problem that was brought up though as the priority policy is isolated and defined by the peripheral driver. Having each peripheral instance have 96 queues in it, most of which are never used, would solve this problem but with a high amount of kernel heap cost. The single queue that we currently use certainly isn't sufficient though. Whatever scheme you come up with, it must level the playing ground between the two different types of application that we're dealing with. 1) Applications that can queue up a large amount of I/O because what they need is easily determined and may even be predeterminable. (dump, mkisofs, dd, etc). 2) Applications whose I/O requirements are small and sporatic. (Loading a program where you are basically waiting on page faults to queue your I/O). -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706061958.NAA00853>