From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423971AbcFMNxV (ORCPT ); Mon, 13 Jun 2016 09:53:21 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:51642 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423729AbcFMNxG (ORCPT ); Mon, 13 Jun 2016 09:53:06 -0400 Date: Mon, 13 Jun 2016 15:53:02 +0200 From: Peter Zijlstra To: Martin Schwidefsky Cc: Heiko Carstens , Greg Kroah-Hartman , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level Message-ID: <20160613135302.GA30909@twins.programming.kicks-ass.net> References: <1465376956-100711-1-git-send-email-heiko.carstens@de.ibm.com> <1465376956-100711-3-git-send-email-heiko.carstens@de.ibm.com> <20160613110621.GV30909@twins.programming.kicks-ass.net> <20160613112230.GA3808@osiris> <20160613130647.GZ30909@twins.programming.kicks-ass.net> <20160613151942.02028e15@mschwide> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160613151942.02028e15@mschwide> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 13, 2016 at 03:19:42PM +0200, Martin Schwidefsky wrote: > On Mon, 13 Jun 2016 15:06:47 +0200 > Peter Zijlstra wrote: > > > On Mon, Jun 13, 2016 at 01:22:30PM +0200, Heiko Carstens wrote: > > > Yes, and actually we are all virt/LPAR always, so this is unfortunately not > > > very easy to do. And yes, I do agree that for the 1:1 case it most likely > > > would make sense, however we don't have any run-time guarantee to stay 1:1. > > > > One option would be to make it a boot option; such that the > > administrator has to set it. At that point, if the admin creates > > multiple LPARs its on him. > > Unfortunately not good enough. The LPAR code tries to optimize the layout > at the time a partition is activated. The landscape of already running > partitions can change at this point. Would not the admin _know_ this? It would be him activating partitions after all, no? > To get around this you would have to activate *all* partitions first and > then start the operating systems in a second step. Arguably, you only care about the single partition covering the entire machine case, so I don't see that being a problem. Again, admin _knows_ this. > And then there is concurrent repair which will move things around if a > piece of memory goes bad. This happens rarely though. That would be magic disturbance indeed, nothing much to do about that.