Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Dec 2012 14:02:18 -0700
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, mjacob@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Unmapped I/O
Message-ID:  <1355950938.1198.227.camel@revolution.hippie.lan>
In-Reply-To: <20121219183600.GX71906@kib.kiev.ua>
References:  <20121219135451.GU71906@kib.kiev.ua> <50D1D2BD.80107@freebsd.org> <50D1ECC5.2070209@freebsd.org> <17252.1355935960@critter.freebsd.dk> <20121219172320.GW71906@kib.kiev.ua> <17479.1355941463@critter.freebsd.dk>  <20121219183600.GX71906@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2012-12-19 at 20:36 +0200, Konstantin Belousov wrote:
> On Wed, Dec 19, 2012 at 06:24:23PM +0000, Poul-Henning Kamp wrote:
> > --------
> > In message <20121219172320.GW71906@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.

On VIVT cache architectures we have to disable caching on all mappings
of a page if there are multiple mappings and any are writable.  This
causes executables to run with the i-cache disabled if its pages are in
the buffer cache, because right now the buffers are mapped with
persistant writable mappings.

So if I understand the conversation so far, these changes are going to
fix that problem by only using ephemeral mappings when needed, right?
If so, that's very good news.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1355950938.1198.227.camel>