Received: by 10.223.185.111 with SMTP id b44csp559211wrg; Fri, 9 Mar 2018 09:24:12 -0800 (PST) X-Google-Smtp-Source: AG47ELscK3biq1PwGmjrb1Lxgpw7LWINR8ZBBXPdeLpCD18JQ1i13IX7+4c5HRfsMLTIhaL6qizy X-Received: by 10.98.186.2 with SMTP id k2mr29191273pff.225.1520616251806; Fri, 09 Mar 2018 09:24:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520616251; cv=none; d=google.com; s=arc-20160816; b=ifI/5uNU4obfBgIMnl3vetccOVA1eF1lKTjU8G0DFxT4l04bLKF8mn133j3KS4OUcA vMAsIu2RnLW0QJ+PhNurxJM7wM7nbB8GNDBssiUpFCPToIDQhDU/GTYBdPIZhvFel8r2 vSNkDbS43nQQz6d9uL0s2kcIpgpfR9Gnpd4qn75Dv70MlavFm/xIz3tNdKHKsj96lvGs /qdChZ0Uf1KcYpsLxDy/XBMVZIS51gplZOS9tQ1BkRIrtrM8mR2Q6rPuGn3o275PiQaP Pmjq1ZSafxuDpyQSDHaEkHNncgPU5RboAKYxs6qxv6O5euOeoDn1y9UKR826Pc7QItR3 b5Ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=QLUpF5A+FTCP4nJiCpMFAYgjOy4mGRobfNG5pv9HTYc=; b=qaRryJkbMyA4KYGhbITay+gWRcNL7XIZSJW8MOuDxV/uI3iI4hb0SlW+bgLreNv9Jq mXEI99bS4Nzi9w/gpnT+H6nUl8VWy9eaIE/pDC4nRfLvMjPXO09jJJcsh1fv9Fhc3tho /gIvYQoBkyrzHGQ+97ufA6CHnl43j3F7Ep6lb0W9JmHenXh2AUjA8R3kmwGI7/4wH/T8 /y22f7aTZZHQsaaCGZIugqXU8ICyOqTqcRtUi4KzAMIApQLrGbqybzVHbvlNXWtjCCbw TraIHeb1T6TMmtutZgw8PBARb8rGT4MigOEbqrzJ1+hdsE8JXEeUXjIdCM6u7i5z7PVh GQlA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y24-v6si1196578plr.31.2018.03.09.09.23.57; Fri, 09 Mar 2018 09:24:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932399AbeCIRXB (ORCPT + 99 others); Fri, 9 Mar 2018 12:23:01 -0500 Received: from mga01.intel.com ([192.55.52.88]:36429 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751301AbeCIRW5 (ORCPT ); Fri, 9 Mar 2018 12:22:57 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2018 09:22:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,446,1515484800"; d="scan'208";a="23354940" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by orsmga007.jf.intel.com with ESMTP; 09 Mar 2018 09:22:56 -0800 Date: Fri, 9 Mar 2018 10:24:45 -0700 From: Keith Busch To: Christoph Hellwig Cc: Ming Lei , Jianchao Wang , axboe@fb.com, sagi@grimberg.me, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH V2] nvme-pci: assign separate irq vectors for adminq and ioq0 Message-ID: <20180309172445.GC14765@localhost.localdomain> References: <1519832921-13915-1-git-send-email-jianchao.w.wang@oracle.com> <20180228164726.GB16536@lst.de> <20180301150329.GB6795@ming.t460p> <20180301161042.GA14799@localhost.localdomain> <20180308074220.GC15748@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180308074220.GC15748@lst.de> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 08, 2018 at 08:42:20AM +0100, Christoph Hellwig wrote: > > So I suspect we'll need to go with a patch like this, just with a way > better changelog. I have to agree this is required for that use case. I'll run some quick tests and propose an alternate changelog. Longer term, the current way we're including offline present cpus either (a) has the driver allocate resources it can't use or (b) spreads the ones it can use thinner than they need to be. Why don't we rerun the irq spread under a hot cpu notifier for only online CPUs?