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 CEAB7C433EF for ; Tue, 28 Jun 2022 20:24:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233244AbiF1UYC (ORCPT ); Tue, 28 Jun 2022 16:24:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233077AbiF1UWj (ORCPT ); Tue, 28 Jun 2022 16:22:39 -0400 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01F3420180 for ; Tue, 28 Jun 2022 13:20:16 -0700 (PDT) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-31772f8495fso128804437b3.4 for ; Tue, 28 Jun 2022 13:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g64p9P5l4RjiVPNQvTNHhvlhE0ueWTzWMizHVjEi9o8=; b=If5kmTn0bvdypLHA6ECF3zWEbgF/CSXXmPswReas42KJSRaXB/EuQSgYHpbwmLJ89d X+QhmnhrPSbkfvfHGLvSRQQ15nE2dVcqIF0chkzSy6D9JRLX6CNWkaaX7KEmSzK2yHsD G71m0ZLx4KQVjhgxN8iTOR1Eq6Wsm07zWt2HziLfTFoErtVU5y6ALXeQRPozcVmC0pVm YuwuBEDVZOQ30nLEMgTdBdpCzbamw0djQKn27WoyNEWTRHdGtBdYQa+QiVkJ0y6V8X3B rYnOo3wKb1tDi+P4PgoZ7ECg+5byUC57pBRYqB0i08SQ9PmPAfHrPwpt67qoB7gMupmS Ki0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g64p9P5l4RjiVPNQvTNHhvlhE0ueWTzWMizHVjEi9o8=; b=Z5JUreigVfYPYZ9ahfKBZJ9/FjALoED4DZqOCNDtCIvbeW+kc7RhE5/WpynmfWUpC9 ItvZjupz8mEk6/aE5HQIygDwF9fLwTHn8ouG087W4rRyVg65zETbD2BBiYHRDONXuUEm Q8nlccmhkKXnQ/+nhS3lISIGBcm+scP9bKk9Heqcquy87xxMPvm85cZt26c4qC/27dYJ 9iE3u0HO3BYm0pl/SUKQWwgegc3stEbdvL4/IIncEfINK1nw9g5QBXdHlyVxvks146ef cEI1xzitKN25SLTr3RDWDyHt5vsA/cKbBCSLwKUWEug9PEpa+xSAxknM4waMeUphr+Be oMDA== X-Gm-Message-State: AJIora8qK6NgzjW8vcBg1ZnrnGFzcO0E+fHIJhJSZnAXCXj9aNsHS+oG p2ZFwZiW7Va1CwECvkura7133eqpjS65R2lvdeElpw== X-Google-Smtp-Source: AGRyM1u/io1Pqriv9LROXyMpAcWMfzeV+H+sxx0JZd70i0nBfnq/F66yqtdKNrQ5ykhlq5ORCprWuwKoJkbo2HxdhjE= X-Received: by 2002:a0d:cc54:0:b0:317:752c:bcf3 with SMTP id o81-20020a0dcc54000000b00317752cbcf3mr23794929ywd.437.1656447615120; Tue, 28 Jun 2022 13:20:15 -0700 (PDT) MIME-Version: 1.0 References: <20220607120530.2447112-1-tarumizu.kohei@fujitsu.com> <086370dd-281f-5ac6-3a0f-f1b80500c668@intel.com> In-Reply-To: <086370dd-281f-5ac6-3a0f-f1b80500c668@intel.com> From: Linus Walleij Date: Tue, 28 Jun 2022 22:20:02 +0200 Message-ID: Subject: Re: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86 To: Dave Hansen 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The memory access pattern statistics from mm/damon was what I suggested as a starting point. We have pretty elaborate heuristics in the kernel to identify the behaviour of processes, one example is the BFQ block scheduler which determines I/O priority weights of processed based on how interactive they are. If we can determine things like that I am pretty sure we can determine how computing intense a task is for example, by using memory access statistics and scheduler information: if the process is constantly READY to run over a few context switches and PC also stays in a certain rage of memory like two adjacent pages then it is probably running a hard kernel, if that is what we need to know here. It doesn't seem too far-fetched? We have the performance counters as well. That should be possible to utilize to get even more precise heuristics? Maybe that is what userspace is using to determine this already. I'm not saying there has to be a simple solution, but maybe there is something like a really complicated solution? We have academic researchers that like to look at things like this. > 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). I don't know if yet another ABI that needs to be maintained helps the situation much, it's just a contract that we will have to maintain for no gain. However if userspace is messing with that register behind our back and we know better, we can just overwrite it with the policy we determine is better in the kernel. Yours, Linus Walleij