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 8E99DC43334 for ; Tue, 28 Jun 2022 21:03:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229545AbiF1VCt (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-acpi@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. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25EC6C43334 for ; Tue, 28 Jun 2022 21:03:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2E9oORjstsEn2qeufDRFLVK3D6r/4jiVPL89iSYDROo=; b=WZN9DCyNSrOMj0 XnpeqUBeEQS5ieko0O7Gp61EpRLC6Y4htvk9eQxjJSeZJ9UOSZuc9/jkMY7yz0v1HC7V5JDK6+V4j r4/Jzxqhh3eO6RlE6XY4H3eVKHUcjnrh4z0Kvy6vKOn/ckU++wQMO79kHturVJaOogW5B526KfaoI Wtl4PiE+Pexs49JP5aMqJZLbwgmLgW3KHQjKM+5VDGscVM1vwO6vlrYX3PtqQrK4o2/g/2svEzR8K oNDUKKb8eTwsD+S7TfslBDJTiN9fTYvrpFBN7ZTuYRtfZtQYp5YoD0j62S0n33bv9AgLFjH3jAjI5 oqwVwYSsB7n0LAtlnSLw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o6IMG-008B68-8X; Tue, 28 Jun 2022 21:02:52 +0000 Received: from mga18.intel.com ([134.134.136.126]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o6IME-008B5G-2u for linux-arm-kernel@lists.infradead.org; Tue, 28 Jun 2022 21:02:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656450170; x=1687986170; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=wZ/uTrA3bjyScAuweu7zLmoZX9qpUo9vDnaXIZOrcKs=; b=j0Ahb3khX+Bq5nkNSKlt7gfsla6eaQogdsKsAAoT0wvJ1Qs/E2m+2Z+E AXWjCzscjBXxlkfJ1vHzpXo0LkuLoPBhVMs4y1BNsFQxQ54oddKEr/Yzr P+fV9v0zD5hymwNCNjRjpstxYEu8IIH1fLEniGiK/YaALgIuWTe+gF9pv FEQFpqqWm4hOAhnyOzLgIDDLRYSqHHBPlRHPhy+aHPY3OUz1u08sQQbKF c2yJjF9qpRyol6vvnOhzMDctkIpKfaIXTBXXye5/DgUYSGtot4mawWA65 4gf9JT1YRIJfJ55jLRpYRxWNiG3Mz/JbGHADrleg9THPGyukfZUq6ZKfF w==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="264887370" X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="264887370" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.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 References: <20220607120530.2447112-1-tarumizu.kohei@fujitsu.com> <086370dd-281f-5ac6-3a0f-f1b80500c668@intel.com> From: Dave Hansen In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220628_140250_220713_87FE90C4 X-CRM114-Status: GOOD ( 19.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "rafael@kernel.org" , "peterz@infradead.org" , "catalin.marinas@arm.com" , "dave.hansen@linux.intel.com" , "ast@kernel.org" , "linux-kernel@vger.kernel.org" , "conor.dooley@microchip.com" , "hpa@zytor.com" , "will@kernel.org" , Paolo Valente , "mchehab+huawei@kernel.org" , "x86@kernel.org" , "linux-acpi@vger.kernel.org" , "mingo@redhat.com" , "kuba@kernel.org" , "eugenis@google.com" , "lenb@kernel.org" , "tarumizu.kohei@fujitsu.com" , "arnd@arndb.de" , "bp@alien8.de" , "tglx@linutronix.de" , "pcc@google.com" , "linux-arm-kernel@lists.infradead.org" , "marcos@orca.pet" , "tony.luck@intel.com" , Greg KH , "peter.chen@kernel.org" , "marcan@marcan.st" , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel