From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Anthony PERARD <anthony.perard@vates.tech>,
Michal Orzel <michal.orzel@amd.com>,
Julien Grall <julien@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order
Date: Thu, 22 Jan 2026 14:05:53 +0100 [thread overview]
Message-ID: <aXIgscqjXmCUqsQn@Mac.lan> (raw)
In-Reply-To: <97127b23-4e4c-4b06-a8bb-b1dad31bf0b0@suse.com>
On Tue, Jan 20, 2026 at 08:25:49AM +0100, Jan Beulich wrote:
> On 19.01.2026 17:13, Jan Beulich wrote:
> > On 15.01.2026 12:18, Roger Pau Monne wrote:
> >> The current logic allows for up to 1G pages to be scrubbed in place, which
> >> can cause the watchdog to trigger in practice. Reduce the limit for
> >> in-place scrubbed allocations to a newly introduced define:
> >> CONFIG_DIRTY_MAX_ORDER. This currently defaults to CONFIG_DOMU_MAX_ORDER
> >> on all architectures. Also introduce a command line option to set the
> >> value.
> >>
> >> Fixes: 74d2e11ccfd2 ("mm: Scrub pages in alloc_heap_pages() if needed")
> >> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> >> ---
> >> Changes since v1:
> >> - Split from previous patch.
> >> - Introduce a command line option to set the limit.
> >> ---
> >> docs/misc/xen-command-line.pandoc | 9 +++++++++
> >> xen/common/page_alloc.c | 23 ++++++++++++++++++++++-
> >> 2 files changed, 31 insertions(+), 1 deletion(-)
> >
> > If you confine the change to page_alloc.c, won't this mean that patch 2's
> > passing of MEMF_no_scrub will then also be bounded (in which case the need
> > for patch 2 would largely disappear)?
>
> This was rubbish, sorry. Besides my being thick-headed I can only attribute
> this to the double negation in !(memflags & MEMF_no_scrub).
>
> I have another concern, though: You effectively undermine ptdom_max_order,
> which is even more of a problem as that would also affect Dom0's ability to
> obtain larger contiguous I/O buffers. Perhaps DIRTY_MAX_ORDER ought to
> default to PTDOM_MAX_ORDER (if HAS_PASSTHROUGH)?
OK, yes, I can default to PTDOM_MAX_ORDER instead of DOMU_MAX_ORDER.
> Yet then command line
> options may also need tying together, such that people using
> "memop-max-order=" to alter (increase) ptdom_max_order won't need to
> additionally use "max-order-dirty="? At which point maybe the new option
> shouldn't be a standalone one, but be added to "memop-max-order=" (despite
> it being effected in alloc_heap_pages())?
I had concerns about adding it to "memop-max-order=" because it's effect
is not limited to "issued by the various kinds of domain", this is an
option that affects all allocations. I could try expanding the option
description to reflect that, but I wasn't sure whether it would lead
to confusion (as all options there are per-domain currently).
Also if added to "memop-max-order=" the parsing function needs to be
adjust a bit to consume an extra parameter in the !HAS_PASSTHROUGH
case (which is not much of an issue).
Thanks, Roger.
next prev parent reply other threads:[~2026-01-22 13:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 11:18 [PATCH v2 0/3] xen/mm: limit in-place scrubbing Roger Pau Monne
2026-01-15 11:18 ` [PATCH v2 1/3] xen/mm: enforce SCRUB_DEBUG checks for MEMF_no_scrub allocations Roger Pau Monne
2026-01-15 11:18 ` [PATCH v2 2/3] xen/mm: allow deferred scrub of physmap populate allocated pages Roger Pau Monne
2026-01-19 13:00 ` Jan Beulich
2026-01-22 12:48 ` Roger Pau Monné
2026-01-22 13:00 ` Jan Beulich
2026-01-15 11:18 ` [PATCH v2 3/3] xen/mm: limit non-scrubbed allocations to a specific order Roger Pau Monne
2026-01-19 16:13 ` Jan Beulich
2026-01-20 7:25 ` Jan Beulich
2026-01-22 13:05 ` Roger Pau Monné [this message]
2026-01-22 13:09 ` Jan Beulich
2026-01-22 12:55 ` Roger Pau Monné
2026-01-22 13:07 ` 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=aXIgscqjXmCUqsQn@Mac.lan \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=sstabellini@kernel.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.