> > > What's pgo_get()? Since you seem to be immersed in UVM, you may be in a
> > > good position to write the manual pages that it so badly lacks. Even if
> > > you just jot some notes on each function, I can write the manual pages.
> >
> > UVM abstracts things that is mapped & put onto the mai
On Mon, Feb 08, 2010 at 12:37:44AM +0900, Masao Uebayashi wrote:
> > What's pgo_get()? Since you seem to be immersed in UVM, you may be in a
> > good position to write the manual pages that it so badly lacks. Even if
> > you just jot some notes on each function, I can write the manual pages.
>
>
Rethinking a bit...
I'm not sure if any evil code allocates struct vm_page dynamically.
(If I read x86/pmap.c correctly, phys_addr is not abused there. :)
Masao
> What's pgo_get()? Since you seem to be immersed in UVM, you may be in a
> good position to write the manual pages that it so badly lacks. Even if
> you just jot some notes on each function, I can write the manual pages.
UVM abstracts things that is mapped & put onto the main memory as "uvm_obj
> > ISTR sparc64 used bits in the physaddr_t for frambuffer mappings.
>
> If so it is well hidden (bus_space_map with LINEAR is used, but AFAICT that
> does nothing special to the uvm page).
Thanks for clarification. Even if something abuses phys_addr, it should be
easily fixed.
I'll commit the
On Sat, Feb 06, 2010 at 10:55:02PM +, Eduardo Horvath wrote:
> ISTR sparc64 used bits in the physaddr_t for frambuffer mappings.
If so it is well hidden (bus_space_map with LINEAR is used, but AFAICT that
does nothing special to the uvm page).
Martin
On Sun, 7 Feb 2010, Masao Uebayashi wrote:
> > This will break mchines that store additional information such as
> > cacheing in the physaddr_t.
>
> Could you be more specific? The only instance accessing phys_addr member I
> can find is:
>
> sys/arch/arm/include/arm32/vmparam.h: (pg)->mdpa
On Wed, Feb 03, 2010 at 03:20:36AM +0900, Masao Uebayashi wrote:
> As I briefly mentioned before, I'll need device page to support XIP. It's
> a struct vm_page *, which is actually a magic value which conveys data from
> pgo_get() to pmap_enter().
What's pgo_get()? Since
> This will break mchines that store additional information such as
> cacheing in the physaddr_t.
Could you be more specific? The only instance accessing phys_addr member I can
find is:
sys/arch/arm/include/arm32/vmparam.h: (pg)->mdpage.pvh_attrs =
(pg)->phys_addr & arm_cache_prefer_mask
M
> Well, i need phys_addr for VM_MDPAGE_INIT to set the initial color of a page
> but
> that could be a second parameter to it.
>
> My concern is that if you have several vm_physseg then finding the right could
> be expensive. Or are we going to sort vm_physmem by increasing pa (and then
> we
>
On Sat, 6 Feb 2010, Masao Uebayashi wrote:
> This kills phys_addr member at all. I don't think UVM_PAGE_TO_PHYS() is
> called often. If we need performance, we should probably vectorize this
> operation, like:
This will break mchines that store additional information such as
cacheing in the ph
On Feb 6, 2010, at 4:20 AM, Masao Uebayashi wrote:
> This kills phys_addr member at all. I don't think UVM_PAGE_TO_PHYS() is
> called often. If we need performance, we should probably vectorize this
> operation, like:
>
> struct vm_page *pgs[16];
> paddr_t pas[16];
> uvm_page
have a vm_page_md mapping for each device vm_physseg.
1:1 mapping of device-page -> vm_page_md. I'll borrow pv_entry hash code
used in x86/pmap.c. (Idea from rm...@.)
Masao
If that patches is OK, next I'll
- move vm_physseg_find() to uvm_page.c, and
- share it with uvm_page_to_phys().
This kills phys_addr member at all. I don't think UVM_PAGE_TO_PHYS() is
called often. If we need performance, we should probably vectorize this
operation, like:
struct vm_page *pgs[16];
paddr_t pas[16];
uvm_page_to_phys(pgs, 16, pas);
Index: sys/uvm/uvm_page.c
==
> > recording physical adderess in each vm_page wastes space given that vm_page
> > is allocated as an array.
> > ie. if we have a way to find the corresponding physseg from a vm_page,
> > its corresponding physical address can be calculated.
> > so i hesitate to propagate the assumption of fast VM
On Feb 2, 2010, at 4:13 PM, YAMAMOTO Takashi wrote:
>> On Feb 2, 2010, at 10:20 AM, Masao Uebayashi wrote:
>>
>>> As I briefly mentioned before, I'll need device page to support XIP. It's
>>> a struct vm_page *, which is actually a magic value
> On Feb 2, 2010, at 10:20 AM, Masao Uebayashi wrote:
>
>> As I briefly mentioned before, I'll need device page to support XIP. It's
>> a struct vm_page *, which is actually a magic value which conveys data from
>> pgo_get() to pmap_enter().
>>
>&g
On Feb 2, 2010, at 10:20 AM, Masao Uebayashi wrote:
> As I briefly mentioned before, I'll need device page to support XIP. It's
> a struct vm_page *, which is actually a magic value which conveys data from
> pgo_get() to pmap_enter().
>
> When a device page is pmap_e
As I briefly mentioned before, I'll need device page to support XIP. It's
a struct vm_page *, which is actually a magic value which conveys data from
pgo_get() to pmap_enter().
When a device page is pmap_enter()'ed, pmap checks if it's a device page or
not, if so, stores a
20 matches
Mail list logo
