From owner-freebsd-current Mon Mar 20 12:47: 5 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 197E037C62C; Mon, 20 Mar 2000 12:30:44 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e2KKrIv02735; Mon, 20 Mar 2000 12:53:18 -0800 (PST) Date: Mon, 20 Mar 2000 12:53:17 -0800 From: Alfred Perlstein To: Poul-Henning Kamp Cc: Matthew Dillon , current@FreeBSD.ORG, bde@FreeBSD.ORG Subject: I/O clustering, Re: patches for test / review Message-ID: <20000320125317.E14789@fw.wintelcom.net> References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20211.953581241@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 08:40:41PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Poul-Henning Kamp [000320 12:03] wrote: > In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes: > >* Poul-Henning Kamp [000320 11:45] wrote: > >> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes: > >> > >> >Keeping the currect cluster code is a bad idea, if the drivers were > >> >taught how to traverse the linked list in the buf struct rather > >> >than just notice "a big buffer" we could avoid a lot of page > >> >twiddling and also allow for massive IO clustering ( > 64k ) > >> > >> Before we redesign the clustering, I would like to know if we > >> actually have any recent benchmarks which prove that clustering > >> is overall beneficial ? > > > >Yes it is really benificial. > > I would like to see some numbers if you have them. No I don't have numbers. Committing a 64k block would require 8 times the overhead of bundling up the RPC as well as transmission and reply, it may be possible to pipeline these commits because you don't really need to wait for one to complete before issueing another request, but it's still 8x the amount of traffic. You also complicate and penalize drivers because not all drivers can add an IO request to an already started transaction, those devices will need to start new transactions for each buffer instead of bundling up the list and passing it all along. Maybe I'm missing something. Is there something to provide a clean way to cluster IO, can you suggest something that won't have this sort of impact on NFS (and elsewhere) if the clustering code was removed? Bruce, what part of the clustering code makes you think of it as hurting us, I thought it was mapping code? > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message