From owner-cvs-all Sun Sep 19 22:27:54 1999 Delivered-To: cvs-all@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id B231315248; Sun, 19 Sep 1999 22:27:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA24178; Sun, 19 Sep 1999 22:27:04 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA77336; Sun, 19 Sep 1999 22:27:04 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Sep 1999 22:27:04 -0700 (PDT) From: Matthew Dillon Message-Id: <199909200527.WAA77336@apollo.backplane.com> To: Greg Lehey Cc: Poul-Henning Kamp , dg@root.com, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: User block device access (was: cvs commit: src/sys/miscfs/specfs spec_vnops.c src/sys/sys vnode.h src/sys/kern vfs_subr.c) References: <16748.937762251@critter.freebsd.dk> <199909191806.LAA73255@apollo.backplane.com> <19990920115556.J55065@freebie.lemis.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk : :Poul-Henning has already replied to this with some figures. I can :confirm what he says; I've been looking a lot at this sort of thing :with Vinum. That doesn't answer the question "why", however. I :suspect that there's something funny in buffer management which is :reducing performance below what it could be. Vinum has a tool which :can be used to measure device queue length, and I've seen widely :differing queue lengths when writing to Vinum block devices: they can :fluctuate between 100 requests and almost none. I can't explain that :by the way Vinum works; it will just malloc and issue requests. About :the only place it could block is in malloc, but the actual memory :usage fluctuates wildly. : :I suspect that this is a bug rather than a feature; the question is, :is it worth following? : :Greg It is, plain and simply, the fact that you are doing one copy (which is in fact direct DMA) in the case of raw I/O and doing two copies (one into the cache - direct DMA, and then a copy to the user buffer ) in the case of buffered I/O. If you apply the mmap() patches found on http://www.backplane.com/FreeBSD4/ and do an mmap based test, you will find that the overhead narrows considerably. There is nothing sinister going on here, buffer copying eats cpu plain and simple. The advantage the block device gives you, apart forom the reblocking is in its ability to cache the data. If you don't take the caching into account then *OF COURSE* the raw I/O will appear to be faster! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message