public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: James Simmons <jsimmons@infradead.org>
Cc: devel@driverdev.osuosl.org,
	Andreas Dilger <andreas.dilger@intel.com>,
	Oleg Drokin <oleg.drokin@intel.com>, NeilBrown <neilb@suse.com>,
	Amir Shehata <amir.shehata@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH v2 11/25] staging: lustre: libcfs: provide debugfs files for distance handling
Date: Fri, 1 Jun 2018 10:41:00 +0200	[thread overview]
Message-ID: <20180601084100.GG19242@kroah.com> (raw)
In-Reply-To: <1527603725-30560-12-git-send-email-jsimmons@infradead.org>

On Tue, May 29, 2018 at 10:21:51AM -0400, James Simmons wrote:
> From: Amir Shehata <amir.shehata@intel.com>
> 
> On systems with large number of NUMA nodes and cores it is easy
> to incorrectly configure their use with Lustre. Provide debugfs
> files which can help track down any issues.
> 
> Signed-off-by: Amir Shehata <amir.shehata@intel.com>
> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7734
> Reviewed-on: http://review.whamcloud.com/18916
> Reviewed-by: Olaf Weber <olaf@sgi.com>
> Reviewed-by: Doug Oucharek <dougso@me.com>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
> ---
> Changelog:
> 
> v1) Initial patch
> v2) Rebased patch. No code changes from original patch
> 
>  drivers/staging/lustre/lnet/libcfs/module.c | 53 +++++++++++++++++++++++++++++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/staging/lustre/lnet/libcfs/module.c b/drivers/staging/lustre/lnet/libcfs/module.c
> index b438d456..d2dfc29 100644
> --- a/drivers/staging/lustre/lnet/libcfs/module.c
> +++ b/drivers/staging/lustre/lnet/libcfs/module.c
> @@ -468,6 +468,53 @@ static int proc_cpt_table(struct ctl_table *table, int write,
>  				    __proc_cpt_table);
>  }
>  
> +static int __proc_cpt_distance(void *data, int write,
> +			       loff_t pos, void __user *buffer, int nob)
> +{
> +	char *buf = NULL;
> +	int len = 4096;
> +	int rc = 0;
> +
> +	if (write)
> +		return -EPERM;
> +
> +	LASSERT(cfs_cpt_tab);

What is this assert really checking?  Why is it needed?

thanks,

greg k-h

  reply	other threads:[~2018-06-01  8:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 14:21 [PATCH v2 00/25] staging: lustre: libcfs: SMP rework James Simmons
2018-05-29 14:21 ` [PATCH v2 01/25] staging: lustre: libcfs: restore UMP handling James Simmons
2018-05-29 23:45   ` NeilBrown
2018-06-13 22:02     ` James Simmons
2018-06-13 22:18       ` [lustre-devel] " Doug Oucharek
2018-06-13 22:29       ` NeilBrown
2018-05-30 10:05   ` Dan Carpenter
2018-05-29 14:21 ` [PATCH v2 02/25] staging: lustre: libcfs: remove useless CPU partition code James Simmons
2018-05-29 14:21 ` [PATCH v2 03/25] staging: lustre: libcfs: rename variable i to cpu James Simmons
2018-05-29 14:21 ` [PATCH v2 04/25] staging: lustre: libcfs: properly handle failure cases in SMP code James Simmons
2018-05-29 14:21 ` [PATCH v2 05/25] staging: lustre: libcfs: replace MAX_NUMNODES with nr_node_ids James Simmons
2018-05-29 14:21 ` [PATCH v2 06/25] staging: lustre: libcfs: remove excess space James Simmons
2018-05-29 14:21 ` [PATCH v2 v2 07/25] staging: lustre: libcfs: replace num_possible_cpus() with nr_cpu_ids James Simmons
2018-06-01  8:29   ` Greg Kroah-Hartman
2018-06-01  8:31   ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 08/25] staging: lustre: libcfs: NUMA support James Simmons
2018-06-01  8:37   ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 09/25] staging: lustre: libcfs: add cpu distance handling James Simmons
2018-05-29 14:21 ` [PATCH v2 10/25] staging: lustre: libcfs: use distance in cpu and node handling James Simmons
2018-05-29 14:21 ` [PATCH v2 11/25] staging: lustre: libcfs: provide debugfs files for distance handling James Simmons
2018-06-01  8:41   ` Greg Kroah-Hartman [this message]
2018-05-29 14:21 ` [PATCH v2 12/25] staging: lustre: libcfs: invert error handling for cfs_cpt_table_print James Simmons
2018-05-29 14:21 ` [PATCH v2 13/25] staging: lustre: libcfs: fix libcfs_cpu coding style James Simmons
2018-06-01  8:39   ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 14/25] staging: lustre: libcfs: use int type for CPT identification James Simmons
2018-05-29 14:21 ` [PATCH v2 15/25] staging: lustre: libcfs: rename i to node for cfs_cpt_set_nodemask James Simmons
2018-05-29 14:21 ` [PATCH v2 16/25] staging: lustre: libcfs: rename i to cpu for cfs_cpt_bind James Simmons
2018-05-29 14:21 ` [PATCH v2 17/25] staging: lustre: libcfs: rename cpumask_var_t variables to *_mask James Simmons
2018-05-29 14:21 ` [PATCH v2 18/25] staging: lustre: libcfs: rename goto label in cfs_cpt_table_print James Simmons
2018-06-01  8:33   ` Greg Kroah-Hartman
2018-05-29 14:21 ` [PATCH v2 19/25] staging: lustre: libcfs: update debug messages James Simmons
2018-05-29 14:22 ` [PATCH v2 20/25] staging: lustre: libcfs: make tolerant to offline CPUs and empty NUMA nodes James Simmons
2018-05-29 14:22 ` [PATCH v2 21/25] staging: lustre: libcfs: report NUMA node instead of just node James Simmons
2018-05-29 14:22 ` [PATCH v2 22/25] staging: lustre: libcfs: update debug messages in CPT code James Simmons
2018-05-29 14:22 ` [PATCH v2 23/25] staging: lustre: libcfs: rework CPU pattern parsing code James Simmons
2018-06-01  8:43   ` Greg Kroah-Hartman
2018-05-29 14:22 ` [PATCH v2 24/25] staging: lustre: libcfs: change CPT estimate algorithm James Simmons
2018-05-29 14:22 ` [PATCH v2 25/25] staging: lustre: ptlrpc: use current CPU instead of hardcoded 0 James Simmons
2018-06-01  8:28 ` [PATCH v2 00/25] staging: lustre: libcfs: SMP rework Greg Kroah-Hartman

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=20180601084100.GG19242@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=amir.shehata@intel.com \
    --cc=andreas.dilger@intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lustre-devel@lists.lustre.org \
    --cc=neilb@suse.com \
    --cc=oleg.drokin@intel.com \
    /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