>>> On 14.03.17 at 08:42, <yu.c.zh...@linux.intel.com> wrote: > On 3/13/2017 7:24 PM, Jan Beulich wrote: >>>>> On 11.03.17 at 09:42, <yu.c.zh...@linux.intel.com> wrote: >>> On 3/11/2017 12:03 AM, Jan Beulich wrote: >>>> But there's a wider understanding issue I'm having here: What is >>>> an "entry" here? Commonly I would assume this to refer to an >>>> individual (4k) page, but it looks like you really mean table entry, >>>> i.e. possibly representing a 2M or 1G page. >>> Well, it should be an entry pointing to a 4K page(only). >>> For p2m_ioreq_server, we shall not meet huge page. Because they are >>> changed from p2m_ram_rw pages >>> in set_mem_type() -> p2m_change_type_one(), which calls p2m_set_entry() >>> with PAGE_ORDER_4K specified. >> And recombination of large pages won't ever end up hitting these? > > Well, by recombination I guess you refer to the POD pages? I do not > think p2m_ioreq_server > pages will be combined now, which means we do not need to worry about > recounting the > p2m_ioreq_server entries while a split happens.
No, I didn't think about PoD here. But indeed I was misremembering: We don't currently make any attempt to transparently recreate large pages. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
