From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH 1/2] sched: add virt sched domain for the guest Date: Wed, 23 May 2012 08:23:06 -0700 Message-ID: <4FBD00DA.5080308@linux.vnet.ibm.com> References: <1337754751-9018-1-git-send-email-kernelfans@gmail.com> <1337754751-9018-2-git-send-email-kernelfans@gmail.com> <1337759644.9698.49.camel@twins> <1337761402.9698.62.camel@twins> <1337762914.9698.65.camel@twins> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Liu ping fan , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, Ingo Molnar , Avi Kivity , Anthony Liguori To: Peter Zijlstra Return-path: In-Reply-To: <1337762914.9698.65.camel@twins> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 05/23/2012 01:48 AM, Peter Zijlstra wrote: > On Wed, 2012-05-23 at 16:34 +0800, Liu ping fan wrote: >> > so we need to migrate some of vcpus from node-B to node-A, or to >> > node-C. > This is absolutely broken, you cannot do that. > > A guest task might want to be node affine, it looks at the topology sets > a cpu affinity mask and expects to stay on that node. > > But then you come along, and flip one of those cpus to another node. The > guest task will now run on another node and get remote memory accesses. Insane, sure. But, if the node has physically gone away, what do we do? I think we've got to either kill the guest, or let it run somewhere suboptimal. Sounds like you're advocating killing it. ;)