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>,
James Simmons <uja.ornl@yahoo.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH v2 00/25] staging: lustre: libcfs: SMP rework
Date: Fri, 1 Jun 2018 10:28:36 +0200 [thread overview]
Message-ID: <20180601082836.GA19242@kroah.com> (raw)
In-Reply-To: <1527603725-30560-1-git-send-email-jsimmons@infradead.org>
On Tue, May 29, 2018 at 10:21:40AM -0400, James Simmons wrote:
> From: James Simmons <uja.ornl@yahoo.com>
>
> Recently lustre support has been expanded to extreme machines with as
> many as a 1000+ cores. On the other end lustre also has been ported
> to platforms like ARM and KNL which have uniquie NUMA and core setup.
> For example some devices exist that have NUMA nodes with no cores.
> With these new platforms the limitations of the Lustre's SMP code
> came to light so a lot of work was needed. This resulted in this
> patch set which has been tested on these platforms.
That's great work, but why is this happening instead of effort to get
this out of the staging tree? I see a mix of "clean this up" combined
with "add this new feature" happening here, and I am getting tired of
it.
I keep saying, "no new features until this gets out of staging", so why
isn't anyone working directly on getting this out of staging? I can
only assume the reason why is because I keep being "nice" and accepting
random new feature additions :(
So, no more, I'm really really really tired of dealing with this
filesystem for all of these years. There is still loads to do to get
this cleaned up and moved out (as my simple debugfs cleanup patch series
showed). So please do it.
Again, I am not going to take any more new feature additions or anything
that does not obviously look like an attempt to get this code cleaned up
into mergable shape. Adding things like "now works on systems with
thousands of CPUs as well as an RPi" is not such work, unless you can
directly show me an end result of cleaner, smaller, and more easily
reviewable code.
This patch series is now dropped, if you think it meets the above
criteria, please feel free to resend it to be judged in this manner.
thanks,
greg k-h
prev parent reply other threads:[~2018-06-01 8:29 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
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 ` Greg Kroah-Hartman [this message]
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=20180601082836.GA19242@kroah.com \
--to=gregkh@linuxfoundation.org \
--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 \
--cc=uja.ornl@yahoo.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