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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1F16C433F5 for ; Thu, 4 Nov 2021 15:13:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D09F361220 for ; Thu, 4 Nov 2021 15:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231340AbhKDPPr (ORCPT ); Thu, 4 Nov 2021 11:15:47 -0400 Received: from mail.skyhub.de ([5.9.137.197]:54292 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231166AbhKDPPq (ORCPT ); Thu, 4 Nov 2021 11:15:46 -0400 Received: from zn.tnic (p200300ec2f0f2b00bdd517953c60a78f.dip0.t-ipconnect.de [IPv6:2003:ec:2f0f:2b00:bdd5:1795:3c60:a78f]) (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 7BC171EC03AD; Thu, 4 Nov 2021 16:13:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1636038787; 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=uIC4IVhy1UxvdSJhwUeavCRqzoU59YQQWy5qdQVSdL4=; b=WsrDMDJbvl65pT/ZD9DT+voSOuUCpaJvTC51nMPTefP9qMnh9kiRKfuhiZbyWVtOd3lxCL n+FnmxLyOm6PqbL3S+atKGdMAYFnM4Vx9wV84m0DkuIo+aixvD0+dXIIiOl5DJJMCcb2pK XeKOk0vr1Lwc3244v6/YP4iZB1r81lA= Date: Thu, 4 Nov 2021 16:13:00 +0100 From: Borislav Petkov To: Kohei Tarumizu Cc: catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 0/5] Add hardware prefetch driver for A64FX and Intel processors Message-ID: References: <20211104052122.553868-1-tarumizu.kohei@fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211104052122.553868-1-tarumizu.kohei@fujitsu.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 04, 2021 at 02:21:17PM +0900, Kohei Tarumizu wrote: > This patch series add hardware prefetch driver register/unregister > function. The purpose of this driver is to provide an interface to > control the hardware prefetch mechanism depending on the application > characteristics. This is all fine and dandy but what I'm missing in this pile of text - at least I couldn't find it - is why do we need this in the upstream kernel? Is there some real-life use case that would benefit from software fiddling with prefetchers or is this one of those, well, we have those controls, lets expose them in the OS? IOW, you need to sell this stuff properly first - then talk design. > create mode 100644 drivers/hwpf/Kconfig > create mode 100644 drivers/hwpf/Makefile > create mode 100644 drivers/hwpf/fujitsu_hwpf.c > create mode 100644 drivers/hwpf/hwpf.c > create mode 100644 drivers/hwpf/intel_hwpf.c > create mode 100644 include/linux/hwpf.h I'm not sure about a wholly separate drivers/hwpf/ - it's not like there are gazillion different hw prefetch drivers. HTH. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96443C433F5 for ; Thu, 4 Nov 2021 15:15:16 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 5F6CA60E73 for ; Thu, 4 Nov 2021 15:15:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5F6CA60E73 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fiPJUeLsfFljvWABIeb2IkP2ri8UNrk6KllXx+60UNc=; b=AG66Igk+PC5n+F hefL7OBySchpwMISYD1GJaZzShQMfWCXDsN8tG/12NyEuN4CdHxE0uqMzhJq/NfpKUdEnHaBj4NNW 7OdXpjZMd1EEzulTUVxPx10fg2TDvgb2157Ph1X90kn9SKuXn4EoXDPBd73rqzx8mSlbNBIG32bVz my1nyFCa25QZngW8QLlbyfOvtypoTLpfDhsmjG5uZz+7XiRbvidDAICVf54uU32WyNSfFp3mf2Xlk QlcO28+JOLFnQaG6K58/dgSHbeY5b4Boy2i8BzrpH7RTiQbY8ItZj3QXm3cc184cBWt2DnSf/gyCA kexytINBPyoDcjMlt//w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mieQU-009DSs-TH; Thu, 04 Nov 2021 15:13:15 +0000 Received: from mail.skyhub.de ([2a01:4f8:190:11c2::b:1457]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mieQR-009DRU-58 for linux-arm-kernel@lists.infradead.org; Thu, 04 Nov 2021 15:13:12 +0000 Received: from zn.tnic (p200300ec2f0f2b00bdd517953c60a78f.dip0.t-ipconnect.de [IPv6:2003:ec:2f0f:2b00:bdd5:1795:3c60:a78f]) (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 7BC171EC03AD; Thu, 4 Nov 2021 16:13:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1636038787; 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=uIC4IVhy1UxvdSJhwUeavCRqzoU59YQQWy5qdQVSdL4=; b=WsrDMDJbvl65pT/ZD9DT+voSOuUCpaJvTC51nMPTefP9qMnh9kiRKfuhiZbyWVtOd3lxCL n+FnmxLyOm6PqbL3S+atKGdMAYFnM4Vx9wV84m0DkuIo+aixvD0+dXIIiOl5DJJMCcb2pK XeKOk0vr1Lwc3244v6/YP4iZB1r81lA= Date: Thu, 4 Nov 2021 16:13:00 +0100 From: Borislav Petkov To: Kohei Tarumizu Cc: catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 0/5] Add hardware prefetch driver for A64FX and Intel processors Message-ID: References: <20211104052122.553868-1-tarumizu.kohei@fujitsu.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211104052122.553868-1-tarumizu.kohei@fujitsu.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211104_081311_360949_F6B990C8 X-CRM114-Status: GOOD ( 15.93 ) 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: , 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 Thu, Nov 04, 2021 at 02:21:17PM +0900, Kohei Tarumizu wrote: > This patch series add hardware prefetch driver register/unregister > function. The purpose of this driver is to provide an interface to > control the hardware prefetch mechanism depending on the application > characteristics. This is all fine and dandy but what I'm missing in this pile of text - at least I couldn't find it - is why do we need this in the upstream kernel? Is there some real-life use case that would benefit from software fiddling with prefetchers or is this one of those, well, we have those controls, lets expose them in the OS? IOW, you need to sell this stuff properly first - then talk design. > create mode 100644 drivers/hwpf/Kconfig > create mode 100644 drivers/hwpf/Makefile > create mode 100644 drivers/hwpf/fujitsu_hwpf.c > create mode 100644 drivers/hwpf/hwpf.c > create mode 100644 drivers/hwpf/intel_hwpf.c > create mode 100644 include/linux/hwpf.h I'm not sure about a wholly separate drivers/hwpf/ - it's not like there are gazillion different hw prefetch drivers. HTH. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel