Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp36252048rwd; Mon, 10 Jul 2023 21:10:01 -0700 (PDT) X-Google-Smtp-Source: APBJJlG+USeMJAplEaOdPS75NiZoG7nxAgS1AwNZN6iRImvGmIU7N2/Pj/SFS/D77d6+Ixt78R90 X-Received: by 2002:a05:6512:2384:b0:4fb:78b1:1cd4 with SMTP id c4-20020a056512238400b004fb78b11cd4mr14549977lfv.49.1689048601357; Mon, 10 Jul 2023 21:10:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689048601; cv=none; d=google.com; s=arc-20160816; b=bRdgHIsKC/8o/lRpS69mFciiHqYxpTr2rmMfytpkK3jS31gK9saPCWV61OPi1rR76P ghnyxWqAWyAzw5CFesqC+jEeOIfk7nMZ2JLSOSyn+X9mmulyO0i0ICyHcl4gMjTDU0uQ ok72BN4BJxvW3avS9/lKC2kKXHiULnz+YuChG7Jtb9lUKoyl2WMN0JLBTIazr0GuOMqU 4fwZ6ecmVir3MsWhdT+qNVfqNAH+lyRNlL2dF/Mw/Y9UcKLYS03THQQXDy6ddBMLyMw6 48EnK9ZNlIPNNgRWG0dKOPnsCMkFXS1IL+nDU6d9kSuIwg4MssAaUzUdkx733Ls5rIEQ Ta5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=RAKJNLVa7Dz/gEOC8l+W1ubVM3SUfpJDz/d6N9kvm8w=; fh=duluCFiX2Gb/EtGKGhDer6PTNnVtuqO6pw+je3pKSvg=; b=yeabm5p72puUne1PDKFJ8/QG4EFAQkAi0S+xXcL86JLWZxmcHhdRNPGj5o9B+GLP6+ QO5uJ+uxLvxNwlGNyTkLQRlv90+zA1I/wPaIwlE6w3suNChq0qPVC/rIsJLrkpq8dLcy 2YW66Uzr42TpwtojsTR5FFTJYQf86Jg7wBwqigHdLfXlMuLwVX093kE/Ezea1IJR4VIK QlNcvHx9VmtJtuNtJNK8AcH0Mj5y5tQtwiE5FhOpHLkgaWZ6gePMcFNEjrwrqbUe5uEv goEhVijaHEVgJaekQoP6JPcIBc3AQjdJUds5yqS7kGwescAXJA8M74EWPmyazEo/L/T2 dctg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dtOCQgye; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i13-20020aa7dd0d000000b0051e19aae8d1si1064407edv.378.2023.07.10.21.09.37; Mon, 10 Jul 2023 21:10:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dtOCQgye; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229871AbjGKDgw (ORCPT + 99 others); Mon, 10 Jul 2023 23:36:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58120 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbjGKDgr (ORCPT ); Mon, 10 Jul 2023 23:36:47 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28895F9 for ; Mon, 10 Jul 2023 20:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689046561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RAKJNLVa7Dz/gEOC8l+W1ubVM3SUfpJDz/d6N9kvm8w=; b=dtOCQgyeZfew8yc4ck0qqex2UgAsZmgASGXB3bhX84Cd0IIDwm/t5uuOCxbIVShvICpGyZ devCD+AhzwrS/VrQ0+r6sU8mnD55RPcM9WN3J3b+nUn46S0OamygbwrcwrY8NNNtK8XoQu n7ooLAi+3uE+lOKbE3bzJYfjf+liPqk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-498-rnGtRtxZNxW8idSVCPY9jA-1; Mon, 10 Jul 2023 23:35:56 -0400 X-MC-Unique: rnGtRtxZNxW8idSVCPY9jA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 765518028B2; Tue, 11 Jul 2023 03:35:55 +0000 (UTC) Received: from localhost (ovpn-12-93.pek2.redhat.com [10.72.12.93]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2547DC52D9C; Tue, 11 Jul 2023 03:35:53 +0000 (UTC) Date: Tue, 11 Jul 2023 11:35:50 +0800 From: Baoquan He To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, Wen Xiong , Keith Busch , Dave Young , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au, Thomas Gleixner Subject: Re: [PATCH 2/2] nvme-pci: use blk_mq_max_nr_hw_queues() to calculate io queues Message-ID: References: <20230708020259.1343736-1-ming.lei@redhat.com> <20230708020259.1343736-3-ming.lei@redhat.com> <20230710064109.GB24519@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/10/23 at 05:14pm, Ming Lei wrote: > On Mon, Jul 10, 2023 at 08:41:09AM +0200, Christoph Hellwig wrote: > > On Sat, Jul 08, 2023 at 10:02:59AM +0800, Ming Lei wrote: > > > Take blk-mq's knowledge into account for calculating io queues. > > > > > > Fix wrong queue mapping in case of kdump kernel. > > > > > > On arm and ppc64, 'maxcpus=1' is passed to kdump command line, see > > > `Documentation/admin-guide/kdump/kdump.rst`, so num_possible_cpus() > > > still returns all CPUs. > > > > That's simply broken. Please fix the arch code to make sure > > it does not return a bogus num_possible_cpus value for these > > That is documented in Documentation/admin-guide/kdump/kdump.rst. > > On arm and ppc64, 'maxcpus=1' is passed for kdump kernel, and "maxcpu=1" > simply keep one of CPU cores as online, and others as offline. I don't know maxcpus on arm and ppc64 well. But maxcpus=1 or nr_cpus=1 are suggested parameter. Because usually nr_cpus=1 is enough to make kdump kernel work well to capture vmcore. However, user is allowed to specify nr_cpus=n (n>1) if they think multiple cpus are needed in kdump kernel. Your hard coding of cpu number in kdump kernel may be not so reasonable. Please cc kexec mailing list when posting so that people can view the whole thread of discussion. Thanks Baoquan > > So Cc our arch(arm & ppc64) & kdump guys wrt. passing 'maxcpus=1' for > kdump kernel. > > > setups, otherwise you'll have to paper over it in all kind of > > drivers. > > The issue is only triggered for drivers which use managed irq & > multiple hw queues. > > > Thanks, > Ming > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >