Re: Introducing non-RAM managed page ("device page")

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

OK, the previous mail was misleading.  Let me rephrease:

- Make struct vm_page opaque.  It's not always a page cache.  And,
- introduce "device pages".

>    UVM allocates a managed page's state (struct vm_page) for each page-sized 
> RAM,
>    because its main purpose is "page cache" - cache of on-disk page-sized 
> data.
>    OTOH, "device pages" is always volatile.  They're not cache.
> 
> i think there are more reasons than simple page cache issues.
>    
>    I'd propose a simple extension to struct vm_page handling.  Make ``struct
>    vm_page *'' either a pointer to its object *or* a magic integral value, 
> which
>    contains physical address (or offset of its physical device's base).  
> Users of
>    struct vm_page * have to check if it's really a RAM's vm_page, like
>    
>       if (uvm_pageisdevice_p(pg)) {
>               ...
>       }
>    
>    If anyone knows things I'm missing, please let me know.
> 
> there are hundreds of uses of this that would need to be updated.  it
> seems like a very invasive hack to support your use-cases.

Some checks need to be added.  If a given struct vm_page * is known, no
extra check is needed.  I don't think those changes will be hundreds.

> can you do it with the "wasteful" full vm_page and see what happens?
> this seems like a premature and extremely invasive optimisation.

It's possible, of course.

> i'd like to see some more support in the MI VM code to handle different
> page sizes (large ones :-) and other similar problems in the future, but
> this does not seem like the right way forward to me.

Masao