From: Paul Durrant <xadimgnik@gmail.com>
To: "'Jan Beulich'" <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
"'Paul Durrant'" <pdurrant@amazon.com>,
"'Roger Pau Monné'" <roger.pau@citrix.com>,
"'Wei Liu'" <wl@xen.org>,
"'Andrew Cooper'" <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 3/6] x86 / pv: do not treat PGC_extra pages as RAM
Date: Tue, 10 Mar 2020 13:32:44 -0000 [thread overview]
Message-ID: <001301d5f6e0$61aa5e00$24ff1a00$@xen.org> (raw)
In-Reply-To: <ae9cc4a6-0378-571c-9d46-0561e536884f@suse.com>
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: 09 March 2020 13:04
> To: paul@xen.org
> Cc: xen-devel@lists.xenproject.org; Paul Durrant <pdurrant@amazon.com>; Andrew Cooper
> <andrew.cooper3@citrix.com>; Wei Liu <wl@xen.org>; Roger Pau Monné <roger.pau@citrix.com>
> Subject: Re: [PATCH v5 3/6] x86 / pv: do not treat PGC_extra pages as RAM
>
> On 09.03.2020 11:23, paul@xen.org wrote:
> > From: Paul Durrant <pdurrant@amazon.com>
> >
> > This patch modifies several places walking the domain's page_list to make
> > them ignore PGC_extra pages:
> >
> > - dump_pageframe_info() should ignore PGC_extra pages in its dump as it
> > determines whether to dump using domain_tot_pages() which also ignores
> > PGC_extra pages.
>
> This argument looks wrong to me: Let's take an example - a domain
> almost fully cleaned up, with 8 "normal" and 3 "extra" pages left.
> domain_tot_pages() returns 8 in this case, i.e. "normal" page
> dumping doesn't get skipped. However, there now won't be any trace
> of the "extra" pages, because they're also not on xenpage_list,
> which gets all its pages dumped in all cases. Correct restoration
> of original behavior would be to dump "normal" pages when there
> are less than 10, and to dump all "extra" pages. (Same of course
> goes for live domains, where "normal" page dumping would be
> skipped in the common case, but xenheap pages would be dumped, and
> hence so should be "extra" ones.) As indicated before, the removal
> of the APIC assist page from xenpage_list was already slightly
> regressing in this regard (as well as in at least one other way,
> I'm afraid), and you're now deliberately making the regression
> even bigger.
I thought the idea here was that the domheap dump loop should be dumping 'normal' pages so it seems reasonable to me that the number of pages dumped to match the value returned by domain_tot_pages().
Would you perhaps be happier if we put 'extra' pages on separate page list, which can be unconditionally dumped so as I transition xenheap pages to 'extra' pages they don't get missed? It would also get rid of some of the other checks for PGC_extra that I have to introduce because they currently end up on the domain's page list.
Paul
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-03-10 13:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 10:22 [Xen-devel] [PATCH v5 0/6] remove one more shared xenheap page: shared_info paul
2020-03-09 10:22 ` [Xen-devel] [PATCH v5 1/6] domain: introduce alloc/free_shared_info() helpers paul
2020-03-09 10:23 ` [Xen-devel] [PATCH v5 2/6] x86 / p2m: replace page_list check in p2m_alloc_table paul
2020-03-09 10:23 ` [Xen-devel] [PATCH v5 3/6] x86 / pv: do not treat PGC_extra pages as RAM paul
2020-03-09 13:04 ` Jan Beulich
2020-03-10 13:32 ` Paul Durrant [this message]
2020-03-10 14:58 ` Jan Beulich
2020-03-10 15:05 ` Paul Durrant
2020-03-10 15:12 ` Jan Beulich
2020-03-10 15:16 ` Paul Durrant
2020-03-10 15:33 ` Jan Beulich
2020-03-10 15:54 ` Paul Durrant
2020-03-09 10:23 ` [Xen-devel] [PATCH v5 4/6] x86 / ioreq: use a MEMF_no_refcount allocation for server pages paul
2020-03-09 10:23 ` [Xen-devel] [PATCH v5 5/6] mm: add 'is_special_page' inline function paul
2020-03-09 13:28 ` Jan Beulich
2020-03-10 16:32 ` Paul Durrant
2020-03-09 10:23 ` [Xen-devel] [PATCH v5 6/6] domain: use PGC_extra domheap page for shared_info paul
2020-03-09 15:56 ` Jan Beulich
2020-03-10 17:33 ` Paul Durrant
2020-03-11 9:16 ` Jan Beulich
[not found] ` <004501d5f7b9$b00e1120$102a3360$@xen.org>
2020-03-12 8:34 ` Jan Beulich
2020-03-12 9:09 ` [Xen-devel] [EXTERNAL][PATCH " Paul Durrant
2020-03-12 9:26 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001301d5f6e0$61aa5e00$24ff1a00$@xen.org' \
--to=xadimgnik@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=jbeulich@suse.com \
--cc=paul@xen.org \
--cc=pdurrant@amazon.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.