Unmapped I/O

Konstantin Belousov kostikbel at gmail.com
Wed Dec 19 18:36:05 UTC 2012


On Wed, Dec 19, 2012 at 06:24:23PM +0000, Poul-Henning Kamp wrote:
> --------
> In message <20121219172320.GW71906 at kib.kiev.ua>, Konstantin Belousov writes:
> 
> >Still, the i386 cannot have much benefit from the unmapped buffers,
> >just because thre is no facilities similar to the direct map for amd64.
> >i386 must use transient mapping even for unmapped buffers to copy
> >the data to the usermode.
> 
> Wrong, a Adaptec 1542 could DMA directly into or out of any spot
> of memory and that could have been mapped in userland but not in
> kernel.
And how this can be used while keeping on-disk data coherent with the
buffer ? It can by used by physio, but not for the normal file i/o, which
caches the file data in the vnode pages or buffers for non-unified cache.
The transient mapping is needed to copy between kernel buffer and usermode
address on i386.

> 
> >Also, as I understand the history, VMIO buffers, or unified page/buffer
> >cache, only appeared in the FreeBSD.
> 
> Correct, but truth to be told, they have probably delayed our
> implementation of unmapped buffers by about 10 years...
Mapped bufers only become an issue on really multi-core machines.
Before large SMP become ubiquitous, additional complexity of the
transient mappings definitely not worth it.

> 
> I don't blame John & David however, making that full leap in
> one go would have required the mythical HeldenProgrammer, there
> were a lot of cruft we had to get out of the way first.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20121219/dfc4b71d/attachment.sig>


More information about the freebsd-arch mailing list