[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180601083754.GE19242@kroah.com>
Date: Fri, 1 Jun 2018 10:37:54 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: James Simmons <jsimmons@...radead.org>
Cc: devel@...verdev.osuosl.org,
Andreas Dilger <andreas.dilger@...el.com>,
Oleg Drokin <oleg.drokin@...el.com>,
NeilBrown <neilb@...e.com>,
Amir Shehata <amir.shehata@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lustre Development List <lustre-devel@...ts.lustre.org>
Subject: Re: [PATCH v2 08/25] staging: lustre: libcfs: NUMA support
On Tue, May 29, 2018 at 10:21:48AM -0400, James Simmons wrote:
> From: Amir Shehata <amir.shehata@...el.com>
>
> This patch adds NUMA node support.
Really? It looks like you just added an empty data structure pointer
that doesn't really do anything at all.
Where are you reading the host memory NUMA information from?
And why would a filesystem care about this type of thing? Are you
going to now mirror what the scheduler does with regards to NUMA
topology issues? How are you going to handle things when the topology
changes? What systems did you test this on? What performance
improvements were seen? What downsides are there with all of this?
I need a whole lot more information here...
> NUMA node information is stored
> in the CPT table. A NUMA node mask is maintained for the entire
> table as well as for each CPT to track the NUMA nodes related to
> each of the CPTs. Add new function cfs_cpt_of_node() which returns
> the CPT of a particular NUMA node.
This doesn't really seem to match up with the code changes from what I
can tell...
thanks,
greg k-h
Powered by blists - more mailing lists