From: Jan Beulich <jbeulich@suse.com>
To: Roger Pau Monne <roger.pau@citrix.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: Mon, 19 Jan 2026 17:13:25 +0100 [thread overview]
Message-ID: <858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com> (raw)
In-Reply-To: <20260115111804.40199-4-roger.pau@citrix.com>
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)?
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1822,6 +1822,15 @@ Specify the deepest C-state CPUs are permitted to be placed in, and
> optionally the maximum sub C-state to be used used. The latter only applies
> to the highest permitted C-state.
>
> +### max-order-dirty
> +> `= <integer>`
> +
> +Specify the maximum allocation order allowed when scrubbing allocated pages
> +in-place. The allocation is non-preemptive, and hence the value must be keep
> +low enough to avoid hogging the CPU for too long.
> +
> +Defaults to `CONFIG_DIRTY_MAX_ORDER` or if unset to `CONFIG_DOMU_MAX_ORDER`.
This may end up misleading, as - despite their names - these aren't really
Kconfig settings that people could easily control in their builds.
> ### max_gsi_irqs (x86)
> > `= <integer>`
I also wonder whether your addition wouldn't more naturally go a litter
further down, by assuming / implying that the sorting used largely ignores
separator characters (underscore vs dash here).
Jan
next prev parent reply other threads:[~2026-01-19 16:14 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 [this message]
2026-01-20 7:25 ` Jan Beulich
2026-01-22 13:05 ` Roger Pau Monné
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=858d73b3-2feb-419f-bf3b-9a264e9f9af8@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.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.