All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: jeremy@goop.org, xen-devel@lists.xensource.com
Subject: Re: [PATCH] [pv-ops domU] support MAXSMP
Date: Fri, 18 Dec 2009 11:24:29 +0100	[thread overview]
Message-ID: <4B2B585D.5000305@redhat.com> (raw)
In-Reply-To: <4B2B625D02000078000269B3@vpn.id2.novell.com>

On 12/18/2009 11:07 AM, Jan Beulich wrote:
>>>> Andrew Jones<drjones@redhat.com>  18.12.09 10:31>>>
>> The MAXSMP config option requires CPUMASK_OFFSTACK, which in turn
>> requires we init the memory for the maps while we bringing up the cpus.
>> MAXSMP also increases NR_CPUS to 4096. This increase in size exposed an
>> issue in the argument construction for mulitcalls from
>> xen_flush_tlb_others. The args should only need space for the actual
>> number of cpus, which with xen is currently only up to 32.
>
> I don't think new code should be making assumptions like this anymore,
> since Xen already supports higher numbers (it's merely the tools which
> so far don't). You're basically trading a compile time detectable large
> value on stack for one that can grow large dynamically (and hence
> require quite a bit more effort to debug, should it ever overrun the
> stack).

I say 32 cpus in my description to point out the large difference 
between NR_CPUS and the actual number used. However, the code shouldn't 
exceed the limits in multicall until something around 2000 cpus.

Keeping it compile-time is good for the stack analysis, but overly 
wasteful when using values like 4096, since the expected case is 
thousands less.  If we want to keep it static then we need to change 
MC_ARGS to also be dependent in some way on NR_CPUS.

Andrew

  reply	other threads:[~2009-12-18 10:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18  9:31 [PATCH] [pv-ops domU] support MAXSMP Andrew Jones
2009-12-18 10:07 ` Jan Beulich
2009-12-18 10:24   ` Andrew Jones [this message]
2009-12-18 13:23     ` Andrew Jones
2009-12-18 13:41       ` Jan Beulich
2009-12-18 13:51         ` Andrew Jones
2011-06-13 19:42       ` Konrad Rzeszutek Wilk
2011-06-14  7:58         ` Andrew Jones
2011-06-14 14:22           ` Konrad Rzeszutek Wilk
2011-06-14 14:55             ` Andrew Jones

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=4B2B585D.5000305@redhat.com \
    --to=drjones@redhat.com \
    --cc=JBeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=xen-devel@lists.xensource.com \
    /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.