linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: tglx@linutronix.de, fenghua.yu@intel.com, tony.luck@intel.com,
	vikas.shivappa@linux.intel.com, gavin.hindman@intel.com,
	jithu.joseph@intel.com, dave.hansen@intel.com, mingo@redhat.com,
	hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4 34/38] x86/intel_rdt: Create debugfs files for pseudo-locking testing
Date: Tue, 22 May 2018 14:02:37 -0700	[thread overview]
Message-ID: <b32a1e6a-1675-0c96-69d3-75bc97a672b4@intel.com> (raw)
In-Reply-To: <20180522194300.GA9656@kroah.com>

Hi Greg,

Thank you very much for taking a look.

On 5/22/2018 12:43 PM, Greg KH wrote:
> On Tue, May 22, 2018 at 04:29:22AM -0700, Reinette Chatre wrote:
>> @@ -149,6 +151,9 @@ struct pseudo_lock_region {
>>  	unsigned int		line_size;
>>  	unsigned int		size;
>>  	void			*kmem;
>> +#ifdef CONFIG_INTEL_RDT_DEBUGFS
>> +	struct dentry		*debugfs_dir;
>> +#endif
> 
> Who cares, just always have this here, it's not going to save you
> anything to #ifdef the .c code everywhere just for this one pointer.

ok

> 
>> @@ -174,6 +180,9 @@ static void pseudo_lock_region_clear(struct pseudo_lock_region *plr)
>>  		plr->d->plr = NULL;
>>  	plr->d = NULL;
>>  	plr->cbm = 0;
>> +#ifdef CONFIG_INTEL_RDT_DEBUGFS
>> +	plr->debugfs_dir = NULL;
>> +#endif
> 
> See?  Ick.
> 
>> +	ret = strtobool(buf, &bv);
>> +	if (ret == 0 && bv) {
>> +		ret = debugfs_file_get(file->f_path.dentry);
>> +		if (unlikely(ret))
>> +			return ret;
> 
> Only ever use unlikely/likely if you can measure the performance
> difference.  Hint, you can't do that here, it's not needed at all.

Here my intention was to follow the current best practices and in the
kernel source I am working with eight of the ten usages of
debugfs_file_get() is followed by an unlikely(). My assumption was thus
that this is a best practice. Thanks for catching this - I'll change it.

>> +#ifdef CONFIG_INTEL_RDT_DEBUGFS
>> +	plr->debugfs_dir = debugfs_create_dir(rdtgrp->kn->name,
>> +					      debugfs_resctrl);
>> +	if (IS_ERR(plr->debugfs_dir)) {
>> +		ret = PTR_ERR(plr->debugfs_dir);
>> +		plr->debugfs_dir = NULL;
>> +		goto out_region;
> 
> Ick no, you never need to care about the return value of a debugfs call.
> You code should never do something different if a debugfs call succeeds
> or fails.  And you are checking it wrong, even if you did want to do
> this :)

Ah - I see I need to be using IS_ERR_OR_NULL() instead of IS_ERR()? If
this is the case then please note that there seems to be quite a few
debugfs_create_dir() calls within the kernel that have the same issue.

>> +	}
>> +
>> +	entry = debugfs_create_file("pseudo_lock_measure", 0200,
>> +				    plr->debugfs_dir, rdtgrp,
>> +				    &pseudo_measure_fops);
>> +	if (IS_ERR(entry)) {
>> +		ret = PTR_ERR(entry);
>> +		goto out_debugfs;
>> +	}
> 
> Again, you don't care, don't do this.
> 
>> +#ifdef CONFIG_INTEL_RDT_DEBUGFS
>> +	debugfs_remove_recursive(rdtgrp->plr->debugfs_dir);
>> +#endif
> 
> Don't put ifdefs in .c files, it's not the Linux way at all.  You can
> make this a lot simpler/easier to maintain over time if you do not.

My mistake - I assumed this would be ok based on my interpretation of
how CONFIG_GENERIC_IRQ_DEBUGFS is used.

I could rework the debugfs code to be contained in a new debugfs
specific .c file that is only compiled if the configuration is set. The
ifdefs will then be restricted to a .h file that contains the
declarations of these debugfs functions with empty variants when the
user did not select the debugfs config option.

Would that be acceptable to you?

Reinette

  reply	other threads:[~2018-05-22 21:02 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-22 11:28 [PATCH V4 00/38] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 01/38] x86/intel_rdt: Document new mode, size, and bit_usage Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 02/38] x86/intel_rdt: Introduce RDT resource group mode Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 03/38] x86/intel_rdt: Associate mode with each RDT resource group Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 04/38] x86/intel_rdt: Introduce resource group's mode resctrl file Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 05/38] x86/intel_rdt: Introduce test to determine if closid is in use Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 06/38] x86/intel_rdt: Make useful functions available internally Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 07/38] x86/intel_rdt: Initialize new resource group with sane defaults Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 08/38] x86/intel_rdt: Introduce new "exclusive" mode Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 09/38] x86/intel_rdt: Enable setting of exclusive mode Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 10/38] x86/intel_rdt: Making CBM name and type more explicit Reinette Chatre
2018-05-22 11:28 ` [PATCH V4 11/38] x86/intel_rdt: Support flexible data to parsing callbacks Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 12/38] x86/intel_rdt: Ensure requested schemata respects mode Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 13/38] x86/intel_rdt: Introduce "bit_usage" to display cache allocations details Reinette Chatre
2018-05-22 21:03   ` Randy Dunlap
2018-05-22 21:09     ` Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 14/38] x86/intel_rdt: Display resource groups' allocations' size in bytes Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 15/38] x86/intel_rdt: Documentation for Cache Pseudo-Locking Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 16/38] x86/intel_rdt: Introduce the Cache Pseudo-Locking modes Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 17/38] x86/intel_rdt: Respect read and write access Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 18/38] x86/intel_rdt: Add utility to test if tasks assigned to resource group Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 19/38] x86/intel_rdt: Add utility to restrict/restore access to resctrl files Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 20/38] x86/intel_rdt: Protect against resource group changes during locking Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 21/38] x86/intel_rdt: Utilities to restrict/restore access to specific files Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 22/38] x86/intel_rdt: Add check to determine if monitoring in progress Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 23/38] x86/intel_rdt: Introduce pseudo-locked region Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 24/38] x86/intel_rdt: Support enter/exit of locksetup mode Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 25/38] x86/intel_rdt: Enable entering of pseudo-locksetup mode Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 26/38] x86/intel_rdt: Split resource group removal in two Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 27/38] x86/intel_rdt: Add utilities to test pseudo-locked region possibility Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 28/38] x86/intel_rdt: Discover supported platforms via prefetch disable bits Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 29/38] x86/intel_rdt: Pseudo-lock region creation/removal core Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 30/38] x86/intel_rdt: Support creation/removal of pseudo-locked region Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 31/38] x86/intel_rdt: resctrl files reflect pseudo-locked information Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 32/38] x86/intel_rdt: Ensure RDT cleanup on exit Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 33/38] x86/intel_rdt: Create resctrl debug area Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 34/38] x86/intel_rdt: Create debugfs files for pseudo-locking testing Reinette Chatre
2018-05-22 19:43   ` Greg KH
2018-05-22 21:02     ` Reinette Chatre [this message]
2018-05-23  8:05       ` Greg KH
2018-05-23 17:19         ` Reinette Chatre
2018-05-23 17:27           ` Greg KH
2018-05-22 11:29 ` [PATCH V4 35/38] x86/intel_rdt: Create character device exposing pseudo-locked region Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 36/38] x86/intel_rdt: More precise L2 hit/miss measurements Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 37/38] x86/intel_rdt: Support L3 cache performance event of Broadwell Reinette Chatre
2018-05-22 11:29 ` [PATCH V4 38/38] x86/intel_rdt: Limit C-states dynamically when pseudo-locking active Reinette Chatre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b32a1e6a-1675-0c96-69d3-75bc97a672b4@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=gavin.hindman@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jithu.joseph@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).