Date: Mon, 20 Mar 2000 11:59:02 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <20000320115902.C14789@fw.wintelcom.net> In-Reply-To: <20102.953580112@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 08:21:52PM %2B0100 References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
* Poul-Henning Kamp <phk@critter.freebsd.dk> [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'm not talking about a redesign of the clustering code as much as making the drivers that take a callback from it actually traverse the 'union cluster_info' rather than relying on the system to fake the pages being contiguous via remapping. There's nothing wrong with the clustering algorithms, it's just the steps it has to take to work with the drivers. > > I would think that track-caches and intelligent drives would gain > much if not more of what clustering was designed to do gain. > > I seem to remember Bruce saying that clustering could even hurt ? Yes because of the gyrations it needs to go through to maintain backward compatibility for devices that want to see "one big buffer" rather than simply follow a linked list of io operations. Not true, at least for 'devices' like NFS where large IO ops issued save milliseconds in overhead. Unless each device was to re-buffer IO (which is silly) or scan the vp passed to it (violating the adstraction and being really scary like my flopped super-commit stuff for NFS) it would make NFS performance even worse for doing commits. Without clustering you'd have to issue a commit RPC for each 8k block With the current clustering you have to issue a commit for each 64k block With an unbounded linked list, well there is only the limit that the filesystem asks for. -- -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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000320115902.C14789>