Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5368410yba; Mon, 13 May 2019 09:40:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqyVRFfhmqZathzEYGpFXX49hDmk+Mb3wDAQ/VadaCPyQ/7jjmonoqXNjC9lq5YZKSQct6N9 X-Received: by 2002:a62:e043:: with SMTP id f64mr35247406pfh.76.1557765611799; Mon, 13 May 2019 09:40:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557765611; cv=none; d=google.com; s=arc-20160816; b=n0+XYIS3HQPjq+yHKBY1E95ILrrvpy48kh1eO9iGtODA42D44CbOcPYLZRvzHhGMpz r/qjyApzCDWbFFV9I1ocMOoxf9sug3Ge56gFEr4SWTzfadYfI3unMqzcxvuntNF0PSIY rxo5E/4AZn+ed6gd47owgiF7n/Z3LQ0D6e9oagiyhj6gyumPYQMfPE4eM+BYKoCPi0qS r07bQMo59ekNw3EHFC46CpVemiXuFYyYNt/jaNr94QuMEfnWq8LwDsyOskEdjOngoV5K CCW8ssP6Bgl3Z1+bU3ckmc/flALVkjhr5+4gyJ7cqD8oLvn0xLjXlgpkJuexZzuZoNF7 aCNw== 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; bh=8Z41Ar+4F/oHlLRKTYGyeC9eNRZhER72LyqfP7/o7KE=; b=LRqE7jVQg0to8OssUNdEQxxhVFaJasaYhuHgcidkK86AeOxFqluXbt6B6Z05HS5iS3 wUR/CNRYTqYmt7SB4rFLbIg2m0BUhNaGaW3TkHUzGo9P2yErSCBIa7PY/kSo073c0cIY Sjt85AfKZMHi5/3oQ4DfdSq7XG3uvo2/Jym+pxsCsWX6du8WGRa2tY7HTFj65Wl0GsWt jpbnxb0MSzoHx9SgMBP0rOWwKAKmoCwYWanXdilXmH++EEUXRZ8tVVoFo9Eh/mldWIB/ QylbE1FeX/95kk18wwb/RDhkmzbZQ7jfSWX/JYabQYkg1gOjVzBhtwY9c/SYeKg3sVxx T0Sw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t24si17127037pga.495.2019.05.13.09.39.55; Mon, 13 May 2019 09:40:11 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729912AbfEMPKV (ORCPT + 99 others); Mon, 13 May 2019 11:10:21 -0400 Received: from mga01.intel.com ([192.55.52.88]:60387 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727339AbfEMPKV (ORCPT ); Mon, 13 May 2019 11:10:21 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2019 08:10:20 -0700 X-ExtLoop1: 1 Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by fmsmga008.fm.intel.com with ESMTP; 13 May 2019 08:10:20 -0700 Date: Mon, 13 May 2019 09:04:58 -0600 From: Keith Busch To: Mario.Limonciello@dell.com Cc: hch@lst.de, keith.busch@intel.com, sagi@grimberg.me, linux-nvme@lists.infradead.org, rafael@kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, kai.heng.feng@canonical.com Subject: Re: [PATCH] nvme/pci: Use host managed power state for suspend Message-ID: <20190513150458.GA15437@localhost.localdomain> References: <20190510212937.11661-1-keith.busch@intel.com> <0080aaff18e5445dabca509d4113eca8@AUSX13MPC105.AMER.DELL.COM> <955722d8fc16425dbba0698c4806f8fd@AUSX13MPC105.AMER.DELL.COM> <20190513143741.GA25500@lst.de> <20190513145522.GA15421@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, May 13, 2019 at 03:05:42PM +0000, Mario.Limonciello@dell.com wrote: > This system power state - suspend to idle is going to freeze threads. > But we're talking a multi threaded kernel. Can't there be a timing problem going > on then too? With a disk flush being active in one task and the other task trying > to put the disk into the deepest power state. If you don't freeze the queues how > can you guarantee that didn't happen? But if an active data flush task is running, then we're not idle and shouldn't go to low power.