From owner-freebsd-hackers Fri Jun 6 03:23:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA11626 for hackers-outgoing; Fri, 6 Jun 1997 03:23:05 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA11621 for ; Fri, 6 Jun 1997 03:22:52 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA01417; Fri, 6 Jun 1997 11:48:03 +0200 From: Luigi Rizzo Message-Id: <199706060948.LAA01417@labinfo.iet.unipi.it> Subject: Re: Extremely poor interactive response under heave SCSI load To: lada@ws6303.gud.siemens.at (Hr.Ladavac) Date: Fri, 6 Jun 1997 11:48:02 +0200 (MET DST) Cc: lada@ws6303-f.gud.siemens.co.at, jkh@time.cdrom.com, henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199706060940.LAA07518@ws6423.gud.siemens.at> from "Hr.Ladavac" at Jun 6, 97 11:39:46 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I have dnot read the previous messages in this thread so I might be wrong, > > but it sounds like a fair bw allocation among flows, much the same as > > you have when you are on a slow ppp link which does not implement priorities, > > and you run an ftp transfer in parallel with a telnet session. > > > > Solutions exist for this problems, i.e. separate the flows (easy for > > tcp/udp connections since the headers clearly identify packets) at the > > bottleneck, and serve the various queues in a round-robin fashion. > > The network drivers do not work like this because it is unlikely that > > long queues develops at a 10Mbit/s interface (but they do on a ppp liink, > > so perhaps this ought to be done in the tun device -- I might work on > > this in the next months). > > > > A similar approach could be used for scheduling disk writes assuming one > > has a way to determine which writes are related. This might not be trivial . > > I wish it were only delayed writes...the reads are delayed as well. sorry I was thinking in 'network mode' where you don't have explicit reads... replace "write" with "request" in my description. > What might be possible is to change the strategy routine for od driver to give > reads priority over writes since read is *much* faster than write on a PD. In > fact, one could clone the od driver into the pd driver with changed strategy. > > The other possibility is to make FFS give priority to metadata reads in > comparison to normal reads and writes. However, I don't know whether that is > really the problem (no FreeBSD box, as previosly stated ): or if that can be > done at all. Sounds non-trivial, though. both solution sound like hacks, similar to prioritizing interactive traffic vs. bulk one on a ppp link. And you still have the problem of classifying requests, which is probably almost as hard as determining "flows" (i.e. streams of requests generated by the same process). I have no idea of what information are available at the fs level, so I will leave some more knowledgeable person the answer. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________