From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 765AE17ADF9 for ; Tue, 6 Aug 2024 14:55:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722956145; cv=none; b=gNcv5sbru/LhBxU8H5454BSk8+ydpFRhUodLqQ8AuCRdcPT2XOfjWKkfhKglljXCE5NK+yyIENyyXBRp6pacySIZO62PjBphtGJ50BefZ3vQqopaQI2cTCfs16xzwV1mi4nEA6UnBTuVJhFgXrpOYQR/H+/hWRmm/z8zbyB00gQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722956145; c=relaxed/simple; bh=5W/f9Go6KqLTcoO7AGO4U5RXIhiU1JoC/JlTAULsf7o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZoQhHOeyAlKtF76BtQx01X27W9lR2TmHxWeFjjWuxF/3zZtX6h5YSoW43PBoPN+68dbBK8c0k6Nl3YD2dlh2kajwdzsOl/lMOXBgMpkz4kVXiqEX9CnsNsCjwhM4qFNRrRqf0CFUSggJkbbBD173usfEAK5Pp2nSE2KnAGOO7vw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=forvEx8Q; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="forvEx8Q" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722956143; 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=5W/f9Go6KqLTcoO7AGO4U5RXIhiU1JoC/JlTAULsf7o=; b=forvEx8QxEJ5TUi4SrYHpyhty9X6z7DjkihTMQ6xgF/MOudDdXPC0NDK0KbwmiBJxaC9c3 V18OaIXL4R6IiyLSAqQnt+9QocwFWtzrvwKmFCNvhR/aKC1egbDmejISIVqOWU7cxsqdJS TF8KMX1CJRkAHIZpt6V1LmnCKMNkae8= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-640-HwAq-aLEOvWa8u616gwxEQ-1; Tue, 06 Aug 2024 10:55:39 -0400 X-MC-Unique: HwAq-aLEOvWa8u616gwxEQ-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A54CF1955BEE; Tue, 6 Aug 2024 14:55:33 +0000 (UTC) Received: from fedora (unknown [10.72.116.14]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A49C91956046; Tue, 6 Aug 2024 14:55:15 +0000 (UTC) Date: Tue, 6 Aug 2024 22:55:09 +0800 From: Ming Lei To: Daniel Wagner Cc: Jens Axboe , Keith Busch , Sagi Grimberg , Thomas Gleixner , Christoph Hellwig , "Martin K. Petersen" , John Garry , "Michael S. Tsirkin" , Jason Wang , Kashyap Desai , Sumit Saxena , Shivasharan S , Chandrakanth patil , Sathya Prakash Veerichetty , Suganath Prabu Subramani , Nilesh Javali , GR-QLogic-Storage-Upstream@marvell.com, Jonathan Corbet , Frederic Weisbecker , Mel Gorman , Hannes Reinecke , Sridhar Balaraman , "brookxu.cn" , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org, virtualization@lists.linux.dev, megaraidlinux.pdl@broadcom.com, mpi3mr-linuxdrv.pdl@broadcom.com, MPT-FusionLinux.pdl@broadcom.com, storagedev@microchip.com, linux-doc@vger.kernel.org Subject: Re: [PATCH v3 15/15] blk-mq: use hk cpus only when isolcpus=io_queue is enabled Message-ID: References: <20240806-isolcpus-io-queues-v3-0-da0eecfeaf8b@suse.de> <20240806-isolcpus-io-queues-v3-15-da0eecfeaf8b@suse.de> Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240806-isolcpus-io-queues-v3-15-da0eecfeaf8b@suse.de> X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 On Tue, Aug 06, 2024 at 02:06:47PM +0200, Daniel Wagner wrote: > When isolcpus=io_queue is enabled all hardware queues should run on the > housekeeping CPUs only. Thus ignore the affinity mask provided by the > driver. Also we can't use blk_mq_map_queues because it will map all CPUs > to first hctx unless, the CPU is the same as the hctx has the affinity > set to, e.g. 8 CPUs with isolcpus=io_queue,2-3,6-7 config What is the expected behavior if someone still tries to submit IO on isolated CPUs? BTW, I don't see any change in blk_mq_get_ctx()/blk_mq_map_queue() in this patchset, that means one random hctx(or even NULL) may be used for submitting IO from isolated CPUs, then there can be io hang risk during cpu hotplug, or kernel panic when submitting bio. Thanks, Ming