From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3zKxQp4hYWzF0ZT for ; Tue, 16 Jan 2018 02:02:10 +1100 (AEDT) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0FF0OGj082489 for ; Mon, 15 Jan 2018 10:02:07 -0500 Received: from e17.ny.us.ibm.com (e17.ny.us.ibm.com [129.33.205.207]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fgscfxefv-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Jan 2018 10:02:07 -0500 Received: from localhost by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 15 Jan 2018 10:02:06 -0500 Subject: Re: [PATCH V2] powerpc/kernel: Add 'ibm, thread-groups' property for CPU allocation To: linuxppc-dev@lists.ozlabs.org, Nathan Fontenot , Michael Ellerman References: <87tvvqbi82.fsf@concordia.ellerman.id.au> From: Michael Bringmann In-Reply-To: <87tvvqbi82.fsf@concordia.ellerman.id.au> Date: Mon, 15 Jan 2018 09:01:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Message-Id: <95dc3b09-63f1-e79e-9fc9-56c4b7b1bcdd@linux.vnet.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 01/12/2018 08:33 PM, Michael Ellerman wrote: > Nathan Fontenot writes: ... >> >> One thing I don't see addressed in the comments or in the code is >> migration support. I think we need to update the thread group mask >> post-migration to reflect the threads per core on the new system. > > Normally I'd agree with you, but I don't see any prospect of the kernel > surviving if the threads per core changes across a migration. We'll have > data structures allocated based on the old value and things will > definitely crash if the value increases. If it shrinks maybe we'd get > away with it, but either way is dicey. > > If there's an expectation that we'll be able to migrate between systems > with different settings then we have a much bigger problem. > > cheers > > >>From what I recall of my tests a few months ago, the device-tree is read in and flattened before the kernel starts processing the migration state. I am trying to get access to a couple of P9 systems on which I may test migration to verify the ordering of events between initializing the kernel and post-migration processing. Regards, -- Michael W. Bringmann Linux Technology Center IBM Corporation Tie-Line 363-5196 External: (512) 286-5196 Cell: (512) 466-0650 mwb@linux.vnet.ibm.com