On Tue, Apr 04, 2006 at 08:53:25PM +0200, Matthias Drochner wrote:
> 
> chuq@chuq.com said:
> > direct I/O is another transient case, it is very much like physio.
> 
> Ah, I see. Just had a look at your latest patch.
> Uses phys_map and does the same as vmapbuf()... so why doesn't
> it use vmapbuf()? Or looking from the other side, why is vmapbuf md?

it doesn't use vmapbuf() mostly because I don't have a struct buf.
I could make a temporary one, but it seems a bit awkward.

vmapbuf() is MD mostly for historical reasons, about the only MD thing
about it is whether or not it can use pmap_kenter_pa() instead of
pmap_enter().  oh yea, the other thing is that phys_map doesn't exist on
all platforms, so I can't use it here in common code.  I guess for now
I'll just do the dance to use vmapbuf().


> > > check against uvmexp.wiredmax and/or
> > > p_rlimit[RLIMIT_MEMLOCK].rlim_cur
> > what cases do you see that need such a check that do not already have one?
> 
> There was one in sysctl(), and there is still the "rrunner" driver
> which passes unchecked ranges to vslock() afaics.
> My local data acquisition applications do vslock() a lot to get
> data into user supplied buffers. (physio() isn't well suited because
> MAXPHYS is too small for good performance)
> Doing the checks separately is ugly, and integrating them into a vslock-
> like call would give us a chance to avoid the inherent race condition.

adding such a thing would be fine, but this is unrelated to direct I/O.
I'll leave this for another time.


> While we are here... many drivers use DMA to transfer data, so wouldn't
> it make sense to formalize this somehow and skip the "map into kvm"
> if possible?

yes, this would also be a fine thing to do, and it's been on my list of
things I'd like to tackle for many years now but it's never gotten to the
top of the pile.

-Chuck