Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4120627iog; Tue, 28 Jun 2022 09:22:21 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t1KL/o7q/1PKrvWhwCtQ8uhUWEBhz9sbcqaQ3LpsSp95iJmgf8q6fxrNQDxiJPY1GjIqNA X-Received: by 2002:a65:6b94:0:b0:3fb:16f4:3620 with SMTP id d20-20020a656b94000000b003fb16f43620mr18420147pgw.464.1656433341177; Tue, 28 Jun 2022 09:22:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656433341; cv=none; d=google.com; s=arc-20160816; b=Rr8BGk+9dyCZBOTYhjWhkDRgGE7SqM/nRPdYn2ULCledQWt8bkMStR2MbuZ+ai+L+O zn4F60/fUtfjkdHKJbckiYSUKwaxM+UKwwomLr6zCau6fSIrtR3RAFpQTOFOGOamqozg FRXZ0HyGqJvgvJHZ0S3EiOAAbsbJueFVTs/SlS/iRxVLQyB1mFqlnephu9d/B6L40ddB LwT5uuC9FRh4gGOUHaInAwoGj7ofeIqYm1tFfZtXthSaQv5AoZLnz9Q5lQ23PJAN/tY2 tLqYnct0wghR1Rzg4jrlYVfI8WRllBojmkel9mL2KidjnHkFF8ErNGy2fxgwoaSM+OVi Ti+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=sxpHWqoUr1eC3k7y4p8PA++Eaco0aGzAfIYUXamPeXQ=; b=LFbdj0vRE9p0P8JN9nz2iqJRjWEw9MvBIfjW/OVSIX2S4MD9cmniVR0P8ThJi1utdA 6QtIw3cJcC/f35ryRIbs2wXeq2/oyKuQMPwNiYWQX749Mq6+vNqsGxgdf0j5GUmbkdHM 9PtADsgJ/VYVnDyUacu+CaPe5J175dZJuzey9+KG5/0IilQ339DnMoiB9fb0SodX1udb eM54QAwF8lczc0uv3cXUrkqiUlrnnKjty8HyQMSYAREeecZ+H0nrZnlvvGjbjCa48xb5 tStZRFR6J17lkzSHZLv4Hx6c1YwT0UJlHyRZkMExK6sVsQJ6OK9qauS3J5WFfQDxQAdD O+2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CnUGHsjF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e8-20020a170902ef4800b0016370e98895si1731694plx.244.2022.06.28.09.22.09; Tue, 28 Jun 2022 09:22:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CnUGHsjF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236306AbiF1Psd (ORCPT + 99 others); Tue, 28 Jun 2022 11:48:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347960AbiF1Pr1 (ORCPT ); Tue, 28 Jun 2022 11:47:27 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3945937A03; Tue, 28 Jun 2022 08:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656431246; x=1687967246; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ZsLTlpPVTkp+QEt+1Ek5ZOFyD2hxJXmK6Jry4VmCBfo=; b=CnUGHsjFBEmWBGGPiAolbfJEqSP+C6I+16ubdgOwmv06nOi5Yje0xh7r o5GnFyxnLx0A91HDRx46ol7inZeSg3bvO6dJACKDzoiH21Rwh5S6vE6iq gE5tiUotj8OoC2ncAKSJPVNsviaDbwFTDxu8dz1S7KbuHi1YPUwFC1xVc +uho9Q4V0P2vJNcCP5U0+LRZOeZA6Q77gkhCA7Lb/H3I3jg62KOI8hvcy IXR+llGsxh3IwJOf18JBdbb9YvL2j7EtNIuUHQ7I/faXyjfZZViG6Qd6A uSOsvAv9h4//aTDc1pbyTY2yV2q++wuNPlgBXCzfM1632IYanPotUYhpV A==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="264817913" X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="264817913" 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 08:47:18 -0700 X-IronPort-AV: E=Sophos;i="5.92,229,1650956400"; d="scan'208";a="587910883" 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 08:47:18 -0700 Message-ID: <086370dd-281f-5ac6-3a0f-f1b80500c668@intel.com> Date: Tue, 28 Jun 2022 08:46:14 -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 , "tarumizu.kohei@fujitsu.com" Cc: 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" References: <20220607120530.2447112-1-tarumizu.kohei@fujitsu.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Otherwise, I'm inclined to say that this series incrementally makes things better in the real world by at least moving folks away from wrmsr(1).