In message <[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
