From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A13EB1E505 for ; Thu, 26 Feb 2026 01:41:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772070069; cv=none; b=WJHR1ob4u2PvzU1oaCBwdW9r/4VStPIGoBtA/1JGR2kvsqahHnT9yD96sEXzUxAl2uAq9Tsd7dPsErzXV5kKEVzW33OsTSwBJ9sZwD408mdoikZTfoBgRWk/uIcy4V/5Wb1uvgG8l9RUbxlsqaiynaA7FKMK9iJGPbEWIWrk1iU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772070069; c=relaxed/simple; bh=gkobbNola3n8rUOaTATtnee2x161bHGjWW/XbfRNDTA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SJ/Jp/yErVK9q+9mw25unLbZXz+1kmS+Jsv+DQWRGkZoMnKeRtWxfCbXU1dlFgz+npq9O760a0gbBGLSdaHy0wsk5nVPRhI1nv4VBoKfR8zXnenvnrkwDi0rOgxnU8YK8axBDsZFSSEYHtbLzrWsvGfOzenZndAf72GNRPNfo8U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K/BxxLVj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K/BxxLVj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5FE5C116D0; Thu, 26 Feb 2026 01:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772070069; bh=gkobbNola3n8rUOaTATtnee2x161bHGjWW/XbfRNDTA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=K/BxxLVjDW2UrQJiRzoMuv4jJNzl/U2Ui8kXDvIrjX2MD1F3/MX3nNoF+3QNnaG3K 7viWDCim4WzXLeykrT5Dst3VjOYxhyd2UIZg3wUFe+Jh8oOux0nutO0DeKYHVt94vZ 6nIZYZBnFSD3TeRX3ak4CXR7nw7oAgKoHueNIvfHBhEcy2GdbWtHBNTsCi176jL67Q qSgfc5bza20YDOWpnNg6TxWKJgg8xBoUaDXilnzIIrT8vgcBqItVpZh2Moe8ut5SVW 2WEmiqnkSR+36FmyzYPbXe2aMfVVx/fjRTlIqnxq8FuHMWlntIJABCFBp6f/rR4V7y lbA59xxKu0igw== Date: Wed, 25 Feb 2026 17:41:07 -0800 From: Namhyung Kim To: David Ahern Cc: Arnaldo Melo , Arnaldo Carvalho de Melo , LKML , Jiri Olsa Subject: Re: perf-trace: improving ioctl details Message-ID: References: <4babff5e-5a27-4e3b-b9c6-16fd2781af35@kernel.org> <2ee59b89-2766-47e7-8527-3541b5549c05@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2ee59b89-2766-47e7-8527-3541b5549c05@kernel.org> On Fri, Feb 20, 2026 at 08:33:01AM -0700, David Ahern wrote: > Sorry for the delayed response; my time seems to evaporate these days. :) > > On 2/19/26 11:49 AM, Namhyung Kim wrote: > >>> Questions for you: > >>> 1. is such an open ended design acceptable for perf-trace? > >> > >> Is it lazy, i.e. only when needed this cache/table gets loaded? > > > > I think it's ok. But I'm curious what's the actual usecases.. do you > > want it for testing kernels and drivers? I guess we can have a default > > table for regular users and provide the option for kernel developers. > > The idea is that ioctl is a very open ended and overloaded uapi, and I > wanted better granularity on how that time was spent. The breakdown by > filename and NR is one level; improving human readability of the NR is > another. > > For the latter, if you look at tools/perf/trace/beauty/ioctl.c, you can > see how human readability for NRs has been improved for specific > subsystems tty, drm, pcm, kvm, ... (the table in ioctl__scnprintf_cmd), > but that design is not going to scale for all of the devices and > drivers, especially those with dynamic major numbers. Allowing runtime > loading of files seemed like an easy way to accommodate the range of > ioctl users in a flexible way. (though it too has limitations given the > multiplexing on specific NRs) I see. So would your patch match ioctl by name instead of number? I'm curious if we can do the same in the beautifier code to handle dynamic numbers.. maybe after checking static numbers. > > > > >> > >>> > >>> 2. if yes, is there any preference on file format (json, yaml, > >>> key-value, ...)? > >> > >> We already have JSON parsing infra, so probably that is better? > > json is used for the PMU files, but it seems to be used only for code > generation (pmu-events/pmu-events.c) at build time, not run time loading > which I was targeting. Hence the question on format. > > > > > JSON should be fine, although it's a bit verbose. I'm fine with plain > > KEY=VALUE format too if it's really a simple mapping. > > key=value format is what I have now. The only awkwardness is a header to > declare the filename it corresponds to and then a further complication > is the need for a wildcard format as there are examples that have > multiple instances (e.g., /dev/infiniband/uverbs*). I think it's ok as we have config files with this format: [section] # comment key = value > > > > >> > >> Great to see you contributing to perf again! > > > > +1 > > > > Thanks. perf-trace code has changed quite a bit over the past 10 years. Yes, it does. :) Thanks, Namhyung