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 33F12C7619A for ; Wed, 12 Apr 2023 09:58:00 +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:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: 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=8GilzJPL+E8EpUXsAz5IBGSIYz79cfFUkvlMv53Q9ww=; b=Su3t/vRoqZ7T4O bvtJA7aL+GLfykfdP6TEHkxiU49I7c/WNRORdzWtYJ/ToG8CtA+e1ms/PD9Ss9ubUVhJv3w6Oe2zG 6KBaVEakThqveKC4JT7+yn144Hjhm0CEZilF3g8QurEXMfES9h4lWNYdHsmLj5S9Z3FzzIV0vjR4b EW2S8xf7Y/TtOfJA+y9bPLaqgzbfch3PP4K6b9k1GeoiMbEqMFBUClYnfNvSNWBZkO54+/jp7uNxk XrQy3M2HjcahCFmGzMXKU71H+fdjDBlEzIrw4qG8xv8JvXImMkgZ8ndcHnC2B4c1/rtPx+dUXKhPv nvXU0uixuguzPC7wGWMQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmXDw-002UPl-2p; Wed, 12 Apr 2023 09:57:08 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pmXDt-002UOA-08 for linux-arm-kernel@lists.infradead.org; Wed, 12 Apr 2023 09:57:06 +0000 Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4PxJ2w0HmHz6J6wc; Wed, 12 Apr 2023 17:54:32 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 12 Apr 2023 10:56:53 +0100 Date: Wed, 12 Apr 2023 10:56:50 +0100 From: Jonathan Cameron To: Greg KH CC: Peter Zijlstra , Yicong Yang , Mark Rutland , Ingo Molnar , Arnaldo Carvalho de Melo , Will Deacon , , , , , Dan Williams , Shaokun Zhang , Jiucheng Xu , "Khuong Dinh" , Robert Richter , Atish Patra , Anup Patel , "Andy Gross" , Bjorn Andersson , Frank Li , Shuai Xue , Vineet Gupta , Shawn Guo , Fenghua Yu , Dave Jiang , Wu Hao , Tom Rix , , Suzuki K Poulose , Liang Kan Subject: Re: [PATCH 01/32] perf: Allow a PMU to have a parent Message-ID: <20230412105650.000014f9@Huawei.com> In-Reply-To: <2023040610-morbidly-supermom-e81c@gregkh> References: <20230404134225.13408-1-Jonathan.Cameron@huawei.com> <20230404134225.13408-2-Jonathan.Cameron@huawei.com> <61f8e489-ae76-38d6-2da0-43cf3c17853d@huawei.com> <20230406111607.00007be5@Huawei.com> <20230406124040.GD392176@hirez.programming.kicks-ass.net> <20230406174445.0000235c@Huawei.com> <2023040610-morbidly-supermom-e81c@gregkh> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100002.china.huawei.com (7.191.160.241) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230412_025705_373089_98AB6880 X-CRM114-Status: GOOD ( 24.87 ) 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, 6 Apr 2023 19:08:45 +0200 Greg KH wrote: > On Thu, Apr 06, 2023 at 05:44:45PM +0100, Jonathan Cameron wrote: > > On Thu, 6 Apr 2023 14:40:40 +0200 > > Peter Zijlstra wrote: > > > > > On Thu, Apr 06, 2023 at 11:16:07AM +0100, Jonathan Cameron wrote: > > > > > > > In the long run I agree it would be good. Short term there are more instances of > > > > struct pmu that don't have parents than those that do (even after this series). > > > > We need to figure out what to do about those before adding checks on it being > > > > set. > > > > > > Right, I don't think you've touched *any* of the x86 PMUs for example, > > > and getting everybody that boots an x86 kernel a warning isn't going to > > > go over well :-) > > > > > > > It was tempting :) "Warning: Parentless PMU: try a different architecture." > > > > I'd love some inputs on what the x86 PMU devices parents should be? > > CPU counters in general tend to just spin out of deep in the architecture code. > > > > My overall favorite is an l2 cache related PMU that is spun up in > > arch/arm/kernel/irq.c init_IRQ() > > > > I'm just not going to try and figure out why... > > Why not change the api to force a parent to be passed in? And if one > isn't, we make it a "virtual" device and throw it in the class for them? Longer term I'd be fine doing that, but I'd like to identify the right parents rather than end up sweeping it under the carpet. Anything we either get completely stuck on (or decide we don't care about) could indeed fall back to a virtual device. Jonathan > > thanks, > > greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel