Re: bus_space_physload(9)

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

Hi,

On Tue, Apr 6, 2010 at 10:41 AM, David Young <dyoung%pobox.com@localhost> wrote:
> I don't think that we should register device memory as part of "usual"
> memory, if that means putting the device memory into the same pool as
> the rest.  The device memory may have different properties than the
> rest.
>
> Properties of the "usual" memory, if by that you mean the system RAM,
> can vary from physical address to physical address.  Think of NUMA.

I think of NUMA, yes. :)

>> For example OpenBSD seems to be trying to use framebuffer's memory
>> for mbufs.
>
> Why is OpenBSD doing that?  Doesn't the framebuffer memory go into an
> mbuf-only pool?

Ah, that makes more sense.

>> It's possible if we prepare the relevant interface and call 
>> uvm_page_physload(9)
>> instead of uvm_page_physload_device(9).  Maybe worth preparing the API.  It'd
>> internally allocate struct vm_page array.  Let UVM use those pages keeping
>> reference counts so that we can safely detach device.  This is kind of NUMA.
>
> It's interesting that you mention device detachment.  I don't think that
> we have any way to ask for the kernel to vacate physical pages, or to
> wait for it to vacate physical pages.  Do we?

I don't think so.

I think we'll need kind of physical page migration to support memory
hot-plug detachment.  NUMA may benefit from page migration too.

Masao