From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [PATCHEs]: support more than 32 VCPUs in guests
Date: Wed, 09 Jun 2010 17:49:52 -0700 [thread overview]
Message-ID: <4C1036B0.4060905@goop.org> (raw)
In-Reply-To: <20100609170825.06a67ff9@mantra.us.oracle.com>
On 06/09/2010 05:08 PM, Mukesh Rathor wrote:
>> Why BUG_ON if the number of cpus is too high? Why not just ignore the
>> excess ones?
>>
> Yeah, that was my first thought also... but then i realized i couldn't
> just ignore the excess cpus in that function, but would need to go back
> and fixup all the cpu_present, cpu_online, etc maps (and any assoc data
> structs, if any), and it just didn't seem worth it in the 2.6.18*
> kernels at least. Would have been easier to do if the vcpu setup
> function returned a value instead of being void.
>
Yes, but if have_vcpu_info_placement ends up being false (which is
tested before any other cpus are brought up) then you can simply fail to
online the ones above the limit.
BUG_ON is way too brutal. You need to fail more softly.
J
next prev parent reply other threads:[~2010-06-10 0:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-09 23:09 [PATCHEs]: support more than 32 VCPUs in guests Mukesh Rathor
2010-06-09 23:44 ` Jeremy Fitzhardinge
2010-06-10 0:08 ` Mukesh Rathor
2010-06-10 0:49 ` Jeremy Fitzhardinge [this message]
2010-06-10 2:13 ` Mukesh Rathor
2010-06-14 9:37 ` Jeremy Fitzhardinge
2010-06-15 2:49 ` Mukesh Rathor
2010-06-15 5:02 ` Konrad Rzeszutek Wilk
2010-06-15 8:30 ` Jeremy Fitzhardinge
2010-06-15 18:45 ` Mukesh Rathor
2010-07-17 1:06 ` Mukesh Rathor
2010-07-17 1:09 ` Jeremy Fitzhardinge
2010-07-17 1:11 ` Mukesh Rathor
2010-07-26 22:57 ` Jeremy Fitzhardinge
2010-07-27 0:37 ` Jeremy Fitzhardinge
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=4C1036B0.4060905@goop.org \
--to=jeremy@goop.org \
--cc=Xen-devel@lists.xensource.com \
--cc=mukesh.rathor@oracle.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.