From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62602C43331 for ; Fri, 6 Sep 2019 22:34:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 362092082C for ; Fri, 6 Sep 2019 22:34:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567809299; bh=t0ccCI+8kZUqKdcNW5Uwzzf08BhcuG881ubPr/huBtA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=yoIyywMfg2+Fk5jVLGo+Z3hP7DhCArtlDTHgAg/HheKEKifts/VqVAVso9Vesz4m4 WjfuY/HOs7uNBFyih9EdOXFVTJvKahLbH9dA1mt+RIgV6RRUv64fF8V5jCl73Mjmu9 kgmz2m9qux657MZHKl1o32G5YVYYYrWpUTUypWnU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392455AbfIFWe5 (ORCPT ); Fri, 6 Sep 2019 18:34:57 -0400 Received: from mga01.intel.com ([192.55.52.88]:20193 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730705AbfIFWe5 (ORCPT ); Fri, 6 Sep 2019 18:34:57 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 15:34:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,474,1559545200"; d="scan'208";a="190955919" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by FMSMGA003.fm.intel.com with ESMTP; 06 Sep 2019 15:34:55 -0700 Date: Fri, 6 Sep 2019 16:25:55 -0600 From: Keith Busch To: Ming Lei Cc: Long Li , Daniel Lezcano , Keith Busch , Hannes Reinecke , Bart Van Assche , "linux-scsi@vger.kernel.org" , Peter Zijlstra , John Garry , LKML , "linux-nvme@lists.infradead.org" , Jens Axboe , Ingo Molnar , Thomas Gleixner , Christoph Hellwig , Sagi Grimberg Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism Message-ID: <20190906222555.GB4260@localhost.localdomain> References: <20190903072848.GA22170@ming.t460p> <6f3b6557-1767-8c80-f786-1ea667179b39@acm.org> <2a8bd278-5384-d82f-c09b-4fce236d2d95@linaro.org> <20190905090617.GB4432@ming.t460p> <6a36ccc7-24cd-1d92-fef1-2c5e0f798c36@linaro.org> <20190906014819.GB27116@ming.t460p> <20190906141858.GA3953@localhost.localdomain> <20190906221920.GA12290@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190906221920.GA12290@ming.t460p> 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 Sat, Sep 07, 2019 at 06:19:21AM +0800, Ming Lei wrote: > On Fri, Sep 06, 2019 at 05:50:49PM +0000, Long Li wrote: > > >Subject: Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism > > > > > >Why are all 8 nvmes sharing the same CPU for interrupt handling? > > >Shouldn't matrix_find_best_cpu_managed() handle selecting the least used > > >CPU from the cpumask for the effective interrupt handling? > > > > The tests run on 10 NVMe disks on a system of 80 CPUs. Each NVMe disk has 32 hardware queues. > > Then there are total 320 NVMe MSI/X vectors, and 80 CPUs, so irq matrix > can't avoid effective CPUs overlapping at all. Sure, but it's at most half, meanwhile the CPU that's dispatching requests would naturally be throttled by the other half who's completions are interrupting that CPU, no?