All of lore.kernel.org
 help / color / mirror / Atom feed
From: Elliott Mitchell <ehem+xen@m5p.com>
To: xen-devel@lists.xenproject.org
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
Subject: [PATCH] x86/pod: Do not fragment PoD memory allocations
Date: Sat, 23 Jan 2021 20:47:38 -0800	[thread overview]
Message-ID: <202101240546.10O5krt7000451@m5p.com> (raw)

Previously p2m_pod_set_cache_target() would fall back to allocating 4KB
pages if 2MB pages ran out.  This is counterproductive since it suggests
severe memory pressure and is likely a precursor to a memory exhaustion
panic.  As such don't try to fill requests for 2MB pages from 4KB pages
if 2MB pages run out.

Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>

---
I'm not including a separate cover message since this is a single hunk.
This really needs some checking in `xl`.  If one has a domain which
sometimes gets started on different hosts and is sometimes modified with
slightly differing settings, one can run into trouble.

In this case most of the time the particular domain is most often used
PV/PVH, but every so often is used as a template for HVM.  Starting it
HVM will trigger PoD mode.  If it is started on a machine with less
memory than others, PoD may well exhaust all memory and then trigger a
panic.

`xl` should likely fail HVM domain creation when the maximum memory
exceeds available memory (never mind total memory).
---
 xen/arch/x86/mm/p2m-pod.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 48e609d1ed..6a7c9ae7d1 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -216,12 +216,10 @@ p2m_pod_set_cache_target(struct p2m_domain *p2m, unsigned long pod_target, int p
         page = alloc_domheap_pages(d, order, 0);
         if ( unlikely(page == NULL) )
         {
-            if ( order == PAGE_ORDER_2M )
-            {
-                /* If we can't allocate a superpage, try singleton pages */
-                order = PAGE_ORDER_4K;
-                goto retry;
-            }
+            /* Superpages allocation failures likely indicate severe memory
+            ** pressure.  Continuing to try to fulfill attempts using 4KB pages
+            ** is likely to exhaust memory and trigger a panic.  As such it is
+            ** NOT worth trying to use 4KB pages to fulfill 2MB page requests.*/
 
             printk("%s: Unable to allocate page for PoD cache (target=%lu cache=%ld)\n",
                    __func__, pod_target, p2m->pod.count);
-- 
2.20.1



             reply	other threads:[~2021-01-24  5:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-24  4:47 Elliott Mitchell [this message]
2021-01-24  4:47 [PATCH] x86/pod: Do not fragment PoD memory allocations Elliott Mitchell
2021-01-25  9:56 ` Jan Beulich
2021-01-25 10:20   ` Andrew Cooper
2021-01-25 17:46   ` Elliott Mitchell
2021-01-26 11:08     ` Jan Beulich
2021-01-26 17:51       ` Elliott Mitchell
2021-01-27  9:47         ` Jan Beulich
2021-01-27 20:12           ` Elliott Mitchell
2021-01-27 21:03             ` Andrew Cooper
2021-01-27 22:28               ` Elliott Mitchell
2021-01-28 10:19                 ` Jan Beulich
2021-01-28 18:26                   ` Elliott Mitchell
2021-01-28 22:42                     ` George Dunlap
2021-01-28 22:56                       ` George Dunlap
2021-01-29 10:56                         ` George Dunlap
2021-01-31 18:13                       ` Elliott Mitchell
2021-02-01  8:15                         ` Roger Pau Monné
2021-02-01 10:35                         ` George Dunlap
2021-02-02  5:58                           ` Elliott Mitchell

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=202101240546.10O5krt7000451@m5p.com \
    --to=ehem+xen@m5p.com \
    --cc=jbeulich@suse.com \
    --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.