From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:58277 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751101AbdBEQk0 (ORCPT ); Sun, 5 Feb 2017 11:40:26 -0500 Date: Sun, 5 Feb 2017 17:40:23 +0100 From: Christoph Hellwig To: Joe Korty Cc: Christoph Hellwig , Keith Busch , linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] genirq: allow assigning affinity to present but not online CPUs Message-ID: <20170205164023.GA9281@lst.de> References: <20170204015809.GA16203@zipoli.ccur.kvm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20170204015809.GA16203@zipoli.ccur.kvm> Sender: linux-block-owner@vger.kernel.org List-Id: linux-block@vger.kernel.org Hi Joe, On Fri, Feb 03, 2017 at 08:58:09PM -0500, Joe Korty wrote: > IIRC, some years ago I ran across a customer system where > the #cpus_present was twice as big as #cpus_possible. > > Hyperthreading was turned off in the BIOS so it was not > entirely out of line for the extra cpus to be declared > present, even though none of them would ever be available > for use. This sounds like a system we should quirk around instead of optimizing for it. Unless I totally misunderstand the idea behind cpu_possible and cpu_present. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@lst.de (Christoph Hellwig) Date: Sun, 5 Feb 2017 17:40:23 +0100 Subject: [PATCH 1/6] genirq: allow assigning affinity to present but not online CPUs In-Reply-To: <20170204015809.GA16203@zipoli.ccur.kvm> References: <20170204015809.GA16203@zipoli.ccur.kvm> Message-ID: <20170205164023.GA9281@lst.de> Hi Joe, On Fri, Feb 03, 2017@08:58:09PM -0500, Joe Korty wrote: > IIRC, some years ago I ran across a customer system where > the #cpus_present was twice as big as #cpus_possible. > > Hyperthreading was turned off in the BIOS so it was not > entirely out of line for the extra cpus to be declared > present, even though none of them would ever be available > for use. This sounds like a system we should quirk around instead of optimizing for it. Unless I totally misunderstand the idea behind cpu_possible and cpu_present.