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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 D0330C4725D for ; Sat, 20 Jan 2024 02:35:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 83A7810EAE0; Sat, 20 Jan 2024 02:35:05 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 87A8410EAE0 for ; Sat, 20 Jan 2024 02:35:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1705718104; x=1737254104; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=M+zKG03ehykpDuQ2Nfq3Qdk9SB7XWsyYerA0zy/TEpU=; b=VS9RDj2z0aHy2PrCltRGQP4g2tfQXujDpE8sb+TdMoueRTsc5qI5WuVX nqngWxhvEoe4fuMXGPZ7GoB8XSWy+iDfefKRHrdEOFZFhY7vgo6l2K0dc a3e7X21R7+4ZHsX/BHrhoaF3JmwRCFJvAkVVgdLuI/ONlXSq0wSYGwvhY lSwcesHUnSPH4NqCxToLtSJ2eSSTZUsiklvcQTSmvwatPBL9rTIqcT2ON oG9BYfbPKRPh1Vw09UuaEMkIzIY61vePz6slhhkCQrMajrWIYKhnAlgEM x6aB/vz7GupK42+OzXz3J8ZAPylc3j7RAlkqyRcmkYkLRDcJtwubAFVOS Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10957"; a="467281468" X-IronPort-AV: E=Sophos;i="6.05,206,1701158400"; d="scan'208";a="467281468" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2024 18:35:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10957"; a="788513763" X-IronPort-AV: E=Sophos;i="6.05,206,1701158400"; d="scan'208";a="788513763" Received: from orsosgc001.jf.intel.com (HELO unerlige-ril.intel.com) ([10.165.21.138]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2024 18:35:03 -0800 Date: Fri, 19 Jan 2024 18:35:03 -0800 Message-ID: <857ck4d960.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: intel-xe@lists.freedesktop.org Subject: Re: [PATCH 02/17] drm/xe/perf/uapi: Add perf_stream_paranoid sysctl In-Reply-To: <87wmtaszr0.wl-ashutosh.dixit@intel.com> References: <20231208064329.2387604-1-ashutosh.dixit@intel.com> <20231208064329.2387604-3-ashutosh.dixit@intel.com> <87wmtaszr0.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Tue, 19 Dec 2023 12:28:51 -0800, Dixit, Ashutosh wrote: > > On Thu, 07 Dec 2023 22:43:14 -0800, Ashutosh Dixit wrote: > > > > +static struct ctl_table perf_ctl_table[] = { > > + { > > + .procname = "perf_stream_paranoid", > > + .data = &xe_perf_stream_paranoid, > > + .maxlen = sizeof(xe_perf_stream_paranoid), > > + .mode = 0644, > > + .proc_handler = proc_dointvec_minmax, > > + .extra1 = SYSCTL_ZERO, > > + .extra2 = SYSCTL_ONE, > > + }, > > + {} > > +}; > > + > > +int xe_perf_sysctl_register(void) > > +{ > > + sysctl_header = register_sysctl("dev/xe", perf_ctl_table); > > + return 0; > > +} > > Any idea why this (and xe_oa_max_sample_rate) is create in /proc, rather > than something attached to the module? > > We would want it to be per module, rather than per device, so that's one > reason. What are the options for creating per module params? One is > module_param itself. In that case this would appear in > "/sys/module/xe/parameters/perf_stream_paranoid" rather than in > "/proc/sys/dev/xe/perf_stream_paranoid". > > Module params are slightly simpler to manage than /proc stuff I think. Any > other reason to prefer one over the other? > > Comments? Looking into i915 history, seems these were created in /proc to follow what the kernel perf subsystem does. However, considering there is nothing common between kernel perf and xe/i915 perf subsystems, there seems to be little reason to have these files where the kernel subsystem places similar files (if the files are are indeed similar). These files might as well created in xe module params or device level sysfs. Module param is probably the least lines of code. Anyway I've left them in /proc for now and probably doesn't matter a lot, but I think we should think a little bit if we should move them to module params or sysfs. Thanks. -- Ashutosh