Re: Device page
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 uvm_page_to_phys() function and wait for a next bump to ride on. Masao
Re: Device page
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_to_phys(pgs, 16, pas); 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 could use a binary sort)?
Re: Device page
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
could use a binary sort)?
There are already sorter bsearch find code.
735 void
736 uvm_page_physload(paddr_t start, paddr_t end, paddr_t avail_start,
737 paddr_t avail_end, int free_list)
738 {
:
819 #elif (VM_PHYSSEG_STRAT == VM_PSTRAT_BSEARCH)
820 {
821 int x;
822 /* sort by address for binary search */
823 for (lcv = 0 ; lcv vm_nphysseg ; lcv++)
824 if (start vm_physmem[lcv].start)
825 break;
826 ps = vm_physmem[lcv];
827 /* move back other entries, if necessary ... */
828 for (x = vm_nphysseg ; x lcv ; x--)
829 /* structure copy */
830 vm_physmem[x] = vm_physmem[x - 1];
831 }
Masao
--
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
pgo_get()? what's that? (was Re: Device page)
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 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. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: Device page
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)-mdpage.pvh_attrs = (pg)-phys_addr arm_cache_prefer_mask ISTR sparc64 used bits in the physaddr_t for frambuffer mappings. Eduardo
Re: Device page
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_enter()'ed, pmap checks if it's a device page or
not, if so, stores a PV into a dedicated vm_physseg for devices. When a
device page is passed to pmap_page_*() (struct vm_page *-oriented functions),
they look for the device vm_physseg, look up a PV header, then look up a PV.
I also want to make these minimal PV handling moved to some MI place -
probably
uvm_page.c. Now we don't define MI PV header yet, I'll allocate struct
vm_page_md *[] for each XIP-capable device. This will be put in uvm_page.c
too.
I'd rather change the arguments to pmap_{zero,copy}_page from paddr_t to struct
vm_page * since it's easier to fetch the physical address from the page than
getting the vm_page from the pa.
It also means that you can easily have a VM_PAGE_DEVICE_PAGE_P(pg) macro to
detect whether this page is a device page or not. No need for the pmap to know
what physseg it is in.
Re: Device page
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 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 PV into a dedicated vm_physseg for devices. When a
device page is passed to pmap_page_*() (struct vm_page *-oriented
functions),
they look for the device vm_physseg, look up a PV header, then look up a PV.
I also want to make these minimal PV handling moved to some MI place -
probably
uvm_page.c. Now we don't define MI PV header yet, I'll allocate struct
vm_page_md *[] for each XIP-capable device. This will be put in uvm_page.c
too.
I'd rather change the arguments to pmap_{zero,copy}_page from paddr_t to
struct vm_page * since it's easier to fetch the physical address from the
page than getting the vm_page from the pa.
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_PAGE_TO_PHYS.
I'd also like to see UVM/pmap use a pfn_t (physical/page frame number) instead
of paddr_t. That would allow most ports to return to using 32bit for that
type. (for a 4K page, a 32 bit PFN would be usable for up to 16TB of physical
address space - more than enough for now).
