Date: Mon, 20 Mar 2000 20:17:13 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <20074.953579833@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 20 Mar 2000 10:46:15 PST." <200003201846.KAA70820@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20074.953579833>