Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3014629pxu; Sat, 10 Oct 2020 16:09:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyT5rkAQR36jmbd1NAe088aatu9DkYRh5KfNDq8hh/DpKZN3gMwB1mXbSSj1QIoTT2txKNi X-Received: by 2002:a17:906:a101:: with SMTP id t1mr20633739ejy.203.1602371372511; Sat, 10 Oct 2020 16:09:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602371372; cv=none; d=google.com; s=arc-20160816; b=b+oCvJmWsgXP75CisRu+9YXihYK5jcqtNsMdXla52/sthAEplOspgwUQKAqJJWHB56 TUkY1noSNadKV8O19x68JzxG1UacRA/36++YNGR1HuxAEa+w3w7rXtPnyaKtrlumtueC LiYQc5vZSa/P6tZNDJCys0qiaEn5gq9zR7qAiW9YdRjFwPhdvFSDQsGfBCImAJi1x7p5 /xscpu46zV5lxjsb3HdCiL4bLB+7gnnB6TDjO2uU+7/wviXrOPMl7TZLqNd6UNddA9i3 zCX3VQny1UZMGruj/zu46JJNT4aQRdqLAsnk+fTdi2OrH2jdYR+f6cq/uHV3k109101j hY1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=2nbGReVghciRvIexFPccXtSAEWKGDKZy+cmvLxhrkeQ=; b=S3Ikv+BqI3IQrkvnOUeDcbc9oT3KrlLRIwr+Acb6Rka+Fz3s+xESB95+A3WKt1cpgm WjHAHKwu17zsB3Xz4VMD4KhL4995Hbt41QZ1cn3Cml0ifEq3qLPO6sO2F7FWsSC7Q6Uj BOjh9tM0hx+YHNRSuMaV6xhUcSwUWUeoI5r9mALjHxYauyWF888wnIM3ctnlwcBbN1t8 NurtIlSNX8x2LGxWM2JrC4jKgCFQ1jAHMoj6tWSZpAr/CVtA/dlgN9OMN+wIleYG8BaQ luFJbQJFemI7WKzQgIlA2RJeQLSDACClt5hlQataXokjEq6Q4umFbgRDTotbrD74QWcz zADA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j1si4334190ejx.446.2020.10.10.16.09.09; Sat, 10 Oct 2020 16:09:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391016AbgJJW7q (ORCPT + 99 others); Sat, 10 Oct 2020 18:59:46 -0400 Received: from mail.ispras.ru ([83.149.199.84]:52594 "EHLO mail.ispras.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732091AbgJJW2i (ORCPT ); Sat, 10 Oct 2020 18:28:38 -0400 Received: from localhost.localdomain (unknown [46.188.10.168]) by mail.ispras.ru (Postfix) with ESMTPSA id A81E440A1DA0; Sat, 10 Oct 2020 22:18:13 +0000 (UTC) From: Alexander Monakov To: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Alexander Monakov , "Rafael J . Wysocki" Subject: [PATCH] intel_idle: mention assumption that wbinvd is not needed Date: Sun, 11 Oct 2020 01:18:06 +0300 Message-Id: <20201010221806.2106-1-amonakov@ispras.ru> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Intel SDM does not explicitly say that entering a C-state via MWAIT will implicitly flush CPU caches as appropriate for that C-state. However, documentation for individual Intel CPU generations does mention this behavior. Since intel_idle binds to any Intel CPU with MWAIT, mention this assumption on MWAIT behavior. In passing, reword opening comment to make it clear that driver can load on any future Intel CPU with MWAIT. Signed-off-by: Alexander Monakov Cc: Rafael J. Wysocki --- Hi, I noticed that one of significant optimizations of intel_idle over acpi_idle is elision of explicit wbinvd: ACPI requires the OS to flush caches when entering C3, and Linux issues an explicit wbinvd to do that, but intel_idle simply issues mwait with the expectation that the CPU will automatically flush caches if needed. To me this is a fairly subtle point that became even more subtle following the update to intel_idle that made it capable to bind to old and future Intel CPUs with MWAIT (by the way, thanks for that!) Can you take this patch to spell out the assumption? drivers/idle/intel_idle.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index f4495841bf68..1e5666cf8763 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -8,7 +8,7 @@ */ /* - * intel_idle is a cpuidle driver that loads on specific Intel processors + * intel_idle is a cpuidle driver that loads on all Intel CPUs with MWAIT * in lieu of the legacy ACPI processor_idle driver. The intent is to * make Linux more efficient on these processors, as intel_idle knows * more than ACPI, as well as make Linux more immune to ACPI BIOS bugs. @@ -20,7 +20,11 @@ * All CPUs have same idle states as boot CPU * * Chipset BM_STS (bus master status) bit is a NOP - * for preventing entry into deep C-stats + * for preventing entry into deep C-states + * + * CPU will flush caches as needed when entering a C-state via MWAIT + * (in contrast to entering ACPI C3, where acpi_idle driver is + * itself responsible for flushing, via WBINVD) */ /* -- 2.26.2