From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A72DCC433F5 for ; Wed, 6 Apr 2022 13:02:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231622AbiDFNEG (ORCPT ); Wed, 6 Apr 2022 09:04:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232684AbiDFNDI (ORCPT ); Wed, 6 Apr 2022 09:03:08 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C68C72EBA52 for ; Wed, 6 Apr 2022 02:31:21 -0700 (PDT) Received: from zn.tnic (p2e55dff8.dip0.t-ipconnect.de [46.85.223.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 68EC11EC0426; Wed, 6 Apr 2022 11:30:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1649237434; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=xNgJ94p4O9/k4M97cHEVb1as3sdFhq6bklaCMoaeeII=; b=D+gBk2yuR9SEsd0Mv7pdVbeS7OW8wP5r2HdSNg67PqFOGHrMF+/DzjFd/Pq8IG0O5zy7IV Ol/u/cWZT9AO/A0GloXQeM+lXzxx4ahCQ7gQ/o0eY2iT7BI6lPqXnuAQ3tA+Z4b87twfSs ZgpQ9pnqoLP/toYJxz+T+U7qmAJSz+8= Date: Wed, 6 Apr 2022 11:30:36 +0200 From: Borislav Petkov To: "Carroll, Lewis" Cc: "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "dave.hansen@linux.intel.com" , "Karny, Wyes" , "Limonciello, Mario" , "Shenoy, Gautham Ranjal" , "Narayan, Ananth" , "Rao, Bharata Bhasker" , "len.brown@intel.com" , "x86@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "hpa@zytor.com" , "chang.seok.bae@intel.com" , "keescook@chromium.org" , "metze@samba.org" , "zhengqi.arch@bytedance.com" , "mark.rutland@arm.com" Subject: Re: [PATCH] x86: Prefer MWAIT over HALT on AMD processors Message-ID: References: <20220405130021.557880-1-wyes.karny@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 05, 2022 at 09:49:27PM +0000, Carroll, Lewis wrote: > Just when I thought I was being thorough. Any of the above will block the > cpuidle driver from loading. As will absence of _CST ACPI methods (add that > as a fourth cause). Yah, put that all in the text over prefer_mwait_c1_over_halt() pls. > We will have to see what we can sanitize. The original performance observation > (packet loss in a networking application) led to discovery of lots of cycles > in the various go-to-sleep-via-halt and wake-from-halt-via-IPI functions. Wyes > collected the raw data on the relative idle+wake-up latency and included that > in the commit msg. Think of that delta as the root cause of the performance > regression in this case. You don't have to write novels - just leave enough breadcrumbs so that people looking at this in the future know *why* this was done. > Yes we are saying use MWAIT instead of HLT on all known (as of today) Zen > uarch CPUs (AMD >= 17h and Hygon). Wyes in his reply from today says that the logic is not that simple so you folks need to define clearly which cases are we talking about here: Zen uarch, MWAIT CPUID bit set/clear, MONITOR bug, , etc. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette