From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fra-out-014.esa.eu-central-1.outbound.mail-perimeter.amazon.com (fra-out-014.esa.eu-central-1.outbound.mail-perimeter.amazon.com [18.199.210.3]) (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 5F72B1E0E14 for ; Fri, 5 Dec 2025 07:34:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.199.210.3 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764920094; cv=none; b=d+IRvpeYk+HvmDNCITSNUf0foYKmRmFo58LqVNFZVhr8NL4bTa5mqk+3dNnbMopwFPc9hH9G+bfzMia1eBH5dy5kOjBabOiQR400Q/dn3hDVvmQp2DQKMjmRDnl5+z9n5bH142QlhN0lnsiRI/EiW2boDo8Fg/2ko7KW7bCtAH4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764920094; c=relaxed/simple; bh=sKISVo78E5iDHciZxVBK8PVcp66+USMDadMiGWVtDKg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=hGwSbIhLSw4brlEXRf6o3XqJS56QnZR/hMwJNuwYv2OZXM4HHu0Rl0O+kohOEBYX2JFtTY1YnPAhTqXgdzwUy5Iuc6EMeLjpZAd4EjxX6vMkCQRCkTcJdck7qGlKhQv0dmarTC6yj7em2Ozj6l8HbKSMgaHVzxAP/RNPzJZzjtE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.de; spf=pass smtp.mailfrom=amazon.de; dkim=pass (2048-bit key) header.d=amazon.de header.i=@amazon.de header.b=HpfP+KWI; arc=none smtp.client-ip=18.199.210.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amazon.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=amazon.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=amazon.de header.i=@amazon.de header.b="HpfP+KWI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazoncorp2; t=1764920081; x=1796456081; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:mime-version: content-transfer-encoding; bh=JqG28S1MxaCpEUBAQ7D9PXYxspGCym86kji6cCqP7v0=; b=HpfP+KWI/VO8M91/xEHLc18CfXcImGAOWKWjvJ2EHgES42PS21jDn/X9 +sf0Ufg8AgRbaYTIsassHvV1PbhXG1jHw0eYiozX5IWmlrT+qVihMX4ye d/FZbZ5+NHpS6Z5A2D2IDsMCDj3nmGdmSRwAC80RcyGFtDQhOZ+Sifo+H jZ+RhvaS8u2ev83hQ094lDSUoFdfVHn/LXLxls/RLZo+w3mnJYmOnNyxv 2yT43VKciQH+KwTAxanIyupmZN9G+CBzNfbOODPsrCuYKVZtTiYKO4Yel HePYbGH+FJ4BOtUCROisCRhe4zYvaXzTctITh76VZ7IxOHTluiE2JYv9C Q==; X-CSE-ConnectionGUID: uOm8kWmpTJ6Q/7w5vRsCSg== X-CSE-MsgGUID: jsPVtH6uRtKnmQSmggC61g== X-IronPort-AV: E=Sophos;i="6.20,251,1758585600"; d="scan'208";a="6168440" Received: from ip-10-6-11-83.eu-central-1.compute.internal (HELO smtpout.naws.eu-central-1.prod.farcaster.email.amazon.dev) ([10.6.11.83]) by internal-fra-out-014.esa.eu-central-1.outbound.mail-perimeter.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Dec 2025 07:33:12 +0000 Received: from EX19MTAEUA002.ant.amazon.com [54.240.197.232:31978] by smtpin.naws.eu-central-1.prod.farcaster.email.amazon.dev [10.0.24.148:2525] with esmtp (Farcaster) id 8976f090-f6c2-4d23-8f4d-e2c6d152203d; Fri, 5 Dec 2025 07:33:12 +0000 (UTC) X-Farcaster-Flow-ID: 8976f090-f6c2-4d23-8f4d-e2c6d152203d Received: from EX19D008EUC004.ant.amazon.com (10.252.51.148) by EX19MTAEUA002.ant.amazon.com (10.252.50.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.29; Fri, 5 Dec 2025 07:33:11 +0000 Received: from EX19D008EUC001.ant.amazon.com (10.252.51.165) by EX19D008EUC004.ant.amazon.com (10.252.51.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.2562.29; Fri, 5 Dec 2025 07:33:11 +0000 Received: from EX19D008EUC001.ant.amazon.com ([fe80::9611:c62b:a7ba:aee1]) by EX19D008EUC001.ant.amazon.com ([fe80::9611:c62b:a7ba:aee1%3]) with mapi id 15.02.2562.029; Fri, 5 Dec 2025 07:33:11 +0000 From: "Heyne, Maximilian" To: Keith Busch CC: Jens Axboe , Christoph Hellwig , "Sagi Grimberg" , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] nvme: Let the blocklayer set timeouts for requests Thread-Topic: [PATCH v2] nvme: Let the blocklayer set timeouts for requests Thread-Index: AQHcZVUAJ2T0ZF2M10Kiw4GQ0UHdFrUSqCSA Date: Fri, 5 Dec 2025 07:33:10 +0000 Message-ID: <20251205-myopia-been-ed739f86@mheyne-amazon> References: <20251204-tests-bryce-8b3b2823@mheyne-amazon> <20251204-pause-lima-29ecb942@mheyne-amazon> In-Reply-To: <20251204-pause-lima-29ecb942@mheyne-amazon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Dec 04, 2025 at 07:34:26PM +0000, Heyne, Maximilian wrote: > On Thu, Dec 04, 2025 at 09:13:35AM -0700, Keith Busch wrote: > > On Thu, Dec 04, 2025 at 02:11:50PM +0000, Heyne, Maximilian wrote: > > > @@ -724,10 +724,8 @@ void nvme_init_request(struct request *req, stru= ct nvme_command *cmd) > > > struct nvme_ns *ns =3D req->q->disk->private_data; > > > = > > > logging_enabled =3D ns->head->passthru_err_log_enabled; > > > - req->timeout =3D NVME_IO_TIMEOUT; > > > } else { /* no queuedata implies admin queue */ > > > logging_enabled =3D nr->ctrl->passthru_err_log_enabled; > > > - req->timeout =3D NVME_ADMIN_TIMEOUT; > > > } > > = > > I was trying to think of any in-kernel path using __submit_sync_cmd with > > an IO queue, and quick search shows there's just one: zns report zones. > > = > > Everything else uses the admin queue, which doesn't have a sysfs tunable > > for its request_queue's default timeout. All we have is the nvme module > > parameter, which is writable after loading. Since that's the only way a > > user can modify the default time for that queue, I think we need to > > leave that req->timeout value as-is. > = > Ok sound like a v3 is needed where I only delete the line with > NVME_IO_TIMEOUT but leave the NVME_ADMIN_TIMEOUT and add a comment about > it. Will prepare such a patch. > = I thought about this a bit more. Considering that the module parameters can be written to produces even more inconsistencies. = With my proposed change we will have the following situation: 1) when a device is probed current settings for IO and admin timeout from the module parameters will be the respective default timeouts 2) almost all admin commands to the device will default to the initial admin timeout 3) almost all IO commands will adhere to whatever is set via sysfs or the initial default -> changes to the module parameters will (mostly) not affect already probed devices When we keep initializing the admin timeouts to the module parameter as you suggest (so half of my patch), we'll have the following situation: 1) same as above 2) some admin commands will use the module parameters admin timeout, some (ioctl's via nvme_submit_user_cmd) will use the admin queue's timeo= ut set in 1). This can be made consistent if we fix nvme_submit_user_cmd. 3) same as above; IO timeout not affected by module parameter changes. -> changes to the module parameters affect only the admin commands but (mostly) not the IO commands which is inconsistent behavior. Therefore, I wonder whether people are actually making changes to the module parameters at runtime to adjust all device's admin timeouts. In that case it's at least broken for ioctl's currently. Should we make that timeout runtime configurable per-device too instead? In summary, I think my patch as-is leads to better consistency. Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Christof Hellmis Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597