[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.
- To: "Kevin Tian" <kevin.tian@xxxxxxxxx>
- From: "Jan Beulich" <JBeulich@xxxxxxxx>
- Date: Fri, 05 Feb 2016 01:38:34 -0700
- Cc: Wei Liu <wei.liu2@xxxxxxxxxx>, IanCampbell <Ian.Campbell@xxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, George Dunlap <dunlapg@xxxxxxxxx>, Zhang Yu <yu.c.zhang@xxxxxxxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxx>, Zhiyuan Lv <zhiyuan.lv@xxxxxxxxx>, IanJackson <Ian.Jackson@xxxxxxxxxx>, "Keir\(Xen.org\)" <keir@xxxxxxx>
- Delivery-date: Fri, 05 Feb 2016 08:38:56 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
>>> On 05.02.16 at 04:44, <kevin.tian@xxxxxxxxx> wrote:
> This is why Yu mentioned earlier whether we can just set a default
> limit which is good for majority of use cases, while extending our
> device mode to drop/recreate some shadow tables upon the limitation
> is hit. I think this matches how today's CPU shadow page table is
> implemented, which also has a limitation of how many shadow pages
> are allowed per-VM.
Except that un-shadowing some victim page in order to shadow one
to make forward progress can there be done in the page fault handler,
i.e. we don't need to up front determine the set of pages to be
shadowed for a certain operation to complete.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
