RE: [PATCH] xen/mm: avoid watchdog timeout in dump_numa() on large domains

[Bernhard Kaindl <bernhard.kaindl@xxxxxxxxxx>]

> >> Replace the page-list walk with node_tot_pages[], a per-node counter
> >> maintained in struct domain. This reduces dump_numa()'s per-domain work
> >> from O(pages) to O(nodes).
>
> > Alternative approch for consideration: Purge dump_numa()? This big a
> > change for making a keyhandler work better is somewhat questionable an
> > approach, imo. The keyhandler isn't there for use in production anyway,
> > it's (primarily) a debugging aid. If the data is still needed (and may
> > e.g. be useful on production systems), make a (preemptible) domctl or
> > sysctl or alike instead?
> 
> Introducing d->node_tot_pages[] is a prerequisite for per-node claims.

That isn't actually the case.

Only of we want to subtracting d->node_tot_pages[node] from the claims.
But that isn't useful in my opinion. 

With multi-node claims (as requested by Jan and Roger), it becomed really
awkward to subtract d->node_tot_pages[node] from the requested claims for
getting the claims to install.

1) That's unnecessary complexity:

   The purpose of claims is to allow domain builders to claim
   memory before populating the physmap of a domain.

   a. A domain builder knows how much memory he needs to populate.

      It is natural to just claim this amount of memory for the physmap.

      It is pointless for a domain builder to:
      populate the physmap without claims and then stake a claims for it.

      It is very awkward to have to call a not yet upstream hypercall to
      get d->node_tot_pages[] for each node and then run this loop:

      for_each_pysmap_node( node )
          claim_request[node] = physmapsize[node] + node_tot_pages[node]

        only for Xen to subtract it again in the claims domctl:

      for_each_requested_claim_node( node )
          d->claim[node] = domctl.requested_claim[node] node_tot_pages[node]

So no, I'm not going to do this insanity.

> Tidying up dump_numa() is just a useful side effect.

Ack, the performance teams of customers were forced to rely on dump_numa()
to get diagnostic information about the NUMA memory distribution of domains,
it would break their tooling (as unsupported as that could be), so it would
be undesirable from a Xen user perspective to just yank it without a sufficient
deprecation period.

Bernhard