[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] Virtual mem map


  • To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Mon, 9 Jan 2006 23:33:34 +0800
  • Delivery-date: Mon, 09 Jan 2006 15:40:07 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcYVHvPT9C65XKT9Qc2CLozHhSzw4QAEak7g
  • Thread-topic: [Xen-ia64-devel] Virtual mem map

>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>Sent: 2006年1月9日 22:18
>
>Remember we need to have:
>* a page entry for every physical page
>* a quick access to such entry.
>The non-virtual mem map is very good for both points, but it can spare a lot
>of memory.  I think my approach is better for memory usage but only slightly
>slower.
>

All by far are talking about pfn_to_page. Another thing you need to think is 
the reverse search. Giving a page struct, how do you derive its page frame 
number (page_to_pfn)? Bother virtually mapped memmap and physical memmap 
preserves a good feature that memory layout is linearly kept in either virtual 
or physical level, thus a simple minus calculation is enough. In your proposal, 
you may walk your offset table to find that index but low efficiency. Or at 
least you need to hack some bits within frame table entry to record index in 
offset table.

Thanks,
Kevin

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.