qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Igor Mammedov <imammedo@redhat.com>
Cc: peter.maydell@linaro.org, ehabkost@redhat.com, agraf@suse.de,
	qemu-devel@nongnu.org, borntraeger@de.ibm.com,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	pbonzini@redhat.com, david@gibson.dropbear.id.au
Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device
Date: Wed, 16 Dec 2015 16:57:54 +0100	[thread overview]
Message-ID: <56718A02.1090701@suse.de> (raw)
In-Reply-To: <20151216164441.270a1f72@igors-macbook-pro.local>

Am 16.12.2015 um 16:44 schrieb Igor Mammedov:
> On Wed, 16 Dec 2015 16:19:06 +0100
> Andreas Färber <afaerber@suse.de> wrote:
> 
>> Am 10.12.2015 um 07:15 schrieb Bharata B Rao:
>>> CPU hotplug granularity
>>> -----------------------
>>> CPU hotplug will now be done in cpu-core device granularity.
>>
>> Nack.
>>
>>> Are there archs that would need thread level CPU addition ?
>>
>> Yes, s390. And for x86 people called for socket level.
> socket level hotplug would be the last resort if we can't agree
> on thread level one. As it would break existing setups where
> user can hotplug 1 core, and  I'd like to avoid it if it is possible.

We still need to keep cpu-add for backwards compatibility, so I am
discussing solely the new device_add interface. My previous x86 series
went to severe hacks trying to keep cpu-add working with sockets&cores.

Attendees in Seattle said that thread-level hot-plug were dangerous for
Linux guests due to assumptions in the (guest's) scheduler breaking for
any incompletely filled cores or sockets. No one present objected to
doing it on socket level. Bharata(?) had a recent patch to catch such
incompletely filled cores on the initial command line and I think we
should seriously consider doing that even if it breaks some fringe use
case - hot-added incomplete cores or sockets remain to be detected.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

  reply	other threads:[~2015-12-16 15:58 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10  6:15 [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 1/9] vl: Don't allow CPU toplogies with partially filled cores Bharata B Rao
2015-12-10 10:25   ` Daniel P. Berrange
2015-12-11  3:24     ` Bharata B Rao
2015-12-14 17:37       ` Eduardo Habkost
2015-12-15  8:41         ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState Bharata B Rao
2015-12-14 17:29   ` Eduardo Habkost
2015-12-15  8:38     ` Bharata B Rao
2015-12-15 15:31       ` Eduardo Habkost
2015-12-16 16:54       ` Igor Mammedov
2015-12-16 19:39         ` Eduardo Habkost
2015-12-16 22:26           ` Igor Mammedov
2015-12-17 18:09             ` Eduardo Habkost
2015-12-18 10:46               ` Igor Mammedov
2015-12-18 15:51                 ` Eduardo Habkost
2015-12-18 16:01                   ` Igor Mammedov
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 3/9] cpu: Don't realize CPU from cpu_generic_init() Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 4/9] cpu: CPU socket backend Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 6/9] cpu: Introduce CPU core device Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 7/9] spapr: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 8/9] target-i386: Set apic_id during CPU initfn Bharata B Rao
2015-12-14 17:44   ` Eduardo Habkost
2015-12-15  8:14     ` Bharata B Rao
2015-12-10  6:15 ` [Qemu-devel] [RFC PATCH v0 9/9] pc: Convert boot CPUs into CPU core device initialization Bharata B Rao
2015-12-10 12:35 ` [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Igor Mammedov
2015-12-11  3:57   ` Bharata B Rao
2015-12-15  5:27     ` Zhu Guihua
2015-12-16 15:16       ` Andreas Färber
2015-12-16 15:11     ` Igor Mammedov
2015-12-17  9:19       ` Peter Krempa
2015-12-16 15:46   ` Andreas Färber
2015-12-16 21:58     ` Igor Mammedov
2015-12-24  1:59       ` Zhu Guihua
2015-12-29 13:52         ` Igor Mammedov
2016-01-01  3:47     ` Bharata B Rao
2016-01-04 12:52       ` Igor Mammedov
2015-12-10 20:25 ` Matthew Rosato
2015-12-14  6:25   ` Bharata B Rao
2015-12-16 15:19 ` Andreas Färber
2015-12-16 15:44   ` Igor Mammedov
2015-12-16 15:57     ` Andreas Färber [this message]
2015-12-16 17:22       ` Igor Mammedov
2015-12-16 22:37         ` Igor Mammedov
2016-01-12  3:54         ` David Gibson

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=56718A02.1090701@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).