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 23362C433EF for ; Tue, 28 Jun 2022 21:03:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230173AbiF1VCt (ORCPT ); Tue, 28 Jun 2022 17:02:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229717AbiF1VCs (ORCPT ); Tue, 28 Jun 2022 17:02:48 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA433393DF; Tue, 28 Jun 2022 14:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656450167; x=1687986167; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=wZ/uTrA3bjyScAuweu7zLmoZX9qpUo9vDnaXIZOrcKs=; b=g/hIDkwQ47/ktR4JtVBeDbfARqwRF65lQARKj80eJ5VAxnH0SgZqp+oZ nvlldvupjNiBnGTKYD6WcePml9afjzxsKMdBQqe39anVH2vB003Ck2CQQ FALbnT0JGXqXmW8tKZzlBJeCxe1MnZqWl9g3Cdb5wFWMindOOaxwSB8O8 tb5g2eAtZulxPZBXMtsI945Tbnn6exfI6447FQB9aztnASKNVYKNLcqIa aR2z0C70TwmlimuFwtCcysTH7SORkaToHefCYln1CEEVU+Cgc4u7Mu59Z GXXhc9Ro0y0Yi6ebauijHAIXtKZ5UcHGC8ayaOnMNByXlYgAC2IiEH5Kw A==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="368160480" X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="368160480" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 14:02:47 -0700 X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="588004851" Received: from staibmic-mobl1.amr.corp.intel.com (HELO [10.209.67.166]) ([10.209.67.166]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 14:02:46 -0700 Message-ID: <6934b82d-db12-8a17-7dea-7bcbd4fe8566@intel.com> Date: Tue, 28 Jun 2022 14:01:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86 Content-Language: en-US To: Linus Walleij Cc: "tarumizu.kohei@fujitsu.com" , Greg KH , "catalin.marinas@arm.com" , "will@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "rafael@kernel.org" , "lenb@kernel.org" , "mchehab+huawei@kernel.org" , "eugenis@google.com" , "tony.luck@intel.com" , "pcc@google.com" , "peterz@infradead.org" , "marcos@orca.pet" , "marcan@marcan.st" , "nicolas.ferre@microchip.com" , "conor.dooley@microchip.com" , "arnd@arndb.de" , "ast@kernel.org" , "peter.chen@kernel.org" , "kuba@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , Paolo Valente , Andrew Morton References: <20220607120530.2447112-1-tarumizu.kohei@fujitsu.com> <086370dd-281f-5ac6-3a0f-f1b80500c668@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/28/22 13:20, Linus Walleij wrote: > On Tue, Jun 28, 2022 at 5:47 PM Dave Hansen wrote: >> On 6/27/22 02:36, Linus Walleij wrote: >>> The right way to solve this is to make the Linux kernel contain the >>> necessary heuristics to identify which tasks and thus cores need this >>> to improve efficiency and then apply it automatically. >> >> I agree in theory. But, I also want a pony in theory. >> >> Any suggestions for how to do this in the real world? > > Well if the knobs are exposed to userspace, how do people using > these knobs know when to turn them? A profiler? perf? All that > data is available to the kernel too. They run their fortran app. Change the MSRs. Run it again. See if it simulated the nuclear weapon blast any faster or slower. Rinse. Repeat. One thing that is missing from the changelog and cover letter here: On x86, there's a 'wrmsr(1)' tool. That took pokes at Model Specific Registers (MSRs) via the /dev/cpu/X/msr interface. That interface is a very, very thinly-veiled wrapper around the WRMSR (WRite MSR) instruction. In other words, on x86, our current interface allows userspace programs to arbitrarily poke at our most sensitive hardware configuration registers. One of the most common reasons users have reported doing this (we have pr_warn()ings about it) is controlling the prefetch hardware. This interface would take a good chunk of the x86 wrmsr(1) audience and convert them over to a less dangerous interface. That's a win on x86. We don't even *remotely* have line-of-sight for a generic solution for the kernel to figure out a single "best" value for these registers.