From owner-freebsd-current Mon Mar 20 11:20:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 497F537C721 for ; Mon, 20 Mar 2000 11:17:28 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA20076; Mon, 20 Mar 2000 20:17:13 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: patches for test / review In-reply-to: Your message of "Mon, 20 Mar 2000 10:46:15 PST." <200003201846.KAA70820@apollo.backplane.com> Date: Mon, 20 Mar 2000 20:17:13 +0100 Message-ID: <20074.953579833@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200003201846.KAA70820@apollo.backplane.com>, Matthew Dillon writes: > Well, let me tell you what the fuzzy goal is first and then maybe we > can work backwards. > > Eventually all physical I/O needs a physical address. The quickest > way to get to a physical address is to be given an array of vm_page_t's > (which can be trivially translated to physical addresses). Not all: PIO access to ATA needs virtual access. RAID5 needs virtual access to calculate parity. > What we want to do is to try to extend VMIO (aka the vm_page_t) all > the way through the I/O system - both VFS and DEV I/O, in order to > remove all the nasty back and forth translations. I agree, but some drivers need mapping we need to cater for those. They could simply call a vm_something(struct buf *) call which would map the pages and things would "just work". For RAID5 we have the opposite problem also: data is created which has only a mapped existance and the b_pages[] array is not populated. > In regards to odd block sizes and offsets the real question is whether > an attempt should be made to translate UIO ops into buffer cache b_pages[] > ops directly, maintaining offsets and odd sizes, or whether we should > back-off to a copy scheme where we allocate b_pages[] for oddly sized > uio's and then copy the data to the uio buffer. I don't know of any non DEV_BSIZE aligned apps that are sufficiently high-profile and high-performance to justify too much code to avoid a copy operation, so I guess that is OK. > My personal preference is to not pollute the VMIO page-passing mechanism > with all sorts of fields to handle weird offsets and sizes. Instead we > ought to take the copy hit for the non-optimal cases, and simply fix all > the programs doing the accesses to pass optimally aligned buffers. For > example, for a raw-I/O on an audio CD track you would pass a page-aligned > buffer with a request size of at least a page (e.g. 4K on IA32) in your > read(), and the raw device would return '2352' as the result and the > returned data would be page-aligned. No protest from here. Encouraging people to think about their data and the handling of them will always have my vote :-) -- 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! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message