Date: Sun, 13 Jun 1999 15:53:04 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: "John S. Dyson" <toor@dyson.iquest.net> Cc: Matthew Dillon <dillon@apollo.backplane.com>, hgoldste@bbs.mpcs.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: problem for the VM gurus Message-ID: <Pine.BSF.3.95.990613153226.2982C-100000@current1.whistle.com> In-Reply-To: <199906131425.JAA06530@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 Jun 1999, John S. Dyson wrote:
>
> Remember that you cannot assume that the mappings stay the same during
> almost any I/O mechanism anymore. The issue of wiring pages and assuming
> constant mapping has to be resolved. A careful definition of whether
> or not one is doing I/O to an address or I/O to a specific piece of
> memory. I know that this is an end condition, but it has consequences
> as to the effects on the design. (I suspect that a punt to do I/O
> to a virtual address is correct, but those change, and also disappear.)
Which brings up the fact that some of us have been talking about making
all IO operations refer to PHYSICAL pages at the strategy layer.
Consider....
for Raw IO:
read() ... user address
physio() ... user pages are faulted to ensur ethey are present,
then physical addreses are extracted and remapped to KV.
addresses strategy.. for DMA devices (most ones we really care about)
... KV addresses are converted to PHYSICAL addresses again.
If we changed the iterface so that the UIO passed from physio to the
strategy routine held an array of physical addresses we could save quite a
bit of work. Also, it wouldn't matter that the pages were or were not
mapped, as long as they are locked in ram. For domb devices that don't do
DMA, the pages would be mapped by some other special scheme.
For pages coming from the buffer cache/vm system, the physical page
addresses should be known already somewhere and the physical UIO
addresses should be pretty trivially collected for the Strategy.
This sounds like a project that could be bitten off and completed pretty
quickly.
1/ redefine UIO correctly to include UIO_PHYSSPACE and an appropriate
change in iovec to allow physical addresses.. (they may be differnt to
virtual addresses in some architectures).. maybe define a phys_iovec[]
and make the pointer in UIO a pointer to a union. (?)
2/ change drivers to be able to handle getting a UIO_PHYSSPACE
request. This would require adding a routine to map such requests into
KV space, for use by the dumb drivers. (all drivers still know how to
handle old type requests)
3/ Change the callers at our leasure (e.g. physio, buffercache etc.)
anyone have comments? I know I discussed this with the NetBSD guys
(e.g. chuq, chuck and jason) and they said htay were looking at similar
things.
possible gotcha's:
you would have to be careful about blocking when allocating teh IOVEC of
physical addresses. maybe they would be allocated as part of allocating
the UIO. (maybe you'd hav eot specify how many pages the UIO
should hold when you allocate it to optimise the allocation.
How this fit's into the proposed rewriting of the iorequest (struct buf)
rewrite that's been rumbling in the background needs evaluation.
julian
p.s. david.. you didn't comment on Matt's subission of a plan for
attacking the deadlock problem. It sounded reasonable to me but I'm only
marginal in this area.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990613153226.2982C-100000>