From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: James Simmons <jsimmons@infradead.org>
Cc: NeilBrown <neilb@suse.com>, Oleg Drokin <oleg.drokin@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>,
lkml <linux-kernel@vger.kernel.org>,
lustre <lustre-devel@lists.lustre.org>
Subject: [lustre-devel] [PATCH 04/19] staging: lustre: discard cfs_time_seconds()
Date: Tue, 9 Jan 2018 09:24:47 +0100 [thread overview]
Message-ID: <20180109082447.GA13112@kroah.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1801081708220.9942@casper.infradead.org>
On Mon, Jan 08, 2018 at 06:04:33PM +0000, James Simmons wrote:
>
> > On Mon, Jan 08, 2018 at 04:52:35PM +0000, James Simmons wrote:
> > >
> > > > cfs_time_seconds() converts a number of seconds to the
> > > > matching number of jiffies.
> > > > The standard way to do this in Linux is "* HZ".
> > > > So discard cfs_time_seconds() and use "* HZ" instead.
> > >
> > > Just to make you aware I have been working for several months on
> > > moving lustre away from using jiffies as much as possible. The
> > > problem with using HZ is that it can vary. So when you have a
> > > parallel file system with batches of nodes that have different
> > > values of HZ you can get very interesting corner cases. So I have
> > > been moving everything over to time64_t and ktime. Also I mostly
> > > have killed off the cfs_time_shift* and crap as well. You see all
> > > work under https://jira.hpdd.intel.com/browse/LU-9019. So many
> > > of the cases you did below don't event exist any more. I was
> > > planning to push those changes after the next merge window.
> >
> > First patch to me "wins", none of this "don't touch this code because
> > I'm going to work on it in the future" stuff. That has been documented
> > to kill contributions and in one case, a whole opensource kernel
> > project.
> >
> > So Neil's patches should be evaluated first, don't develop behind closed
> > walls like you are doing
>
> What I'm saying is my work had been tested and various bugs have
> been worked out before it gets to you. His work is new and untested. His
> work can be evaluated first but that doesn't mean it ready to land first.
> The wait event changes is a pretty big change that can have unseen
> consequences.
And how in the world am I supposed to know that your work is somehow
better than his? I don't see your work in my inbox at all, so am I
supposed to just guess?
Come on, you all know how kernel development works, and it sure isn't
this way.
> > I've merged almost all of them now, except for the ones that broke the
> > build :)
>
> He just posted a updated the version of the l_wait_event changes a few
> hours ago based on feed back. Please give it more than a few hours to
> bake. I like to test them to make sure things don't break. I hate to
> find out it breaks things and have it reverted. Please.
reverts are trivial, delaying patch acceptance for no good reason is
not.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: James Simmons <jsimmons@infradead.org>
Cc: NeilBrown <neilb@suse.com>, Oleg Drokin <oleg.drokin@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>,
lkml <linux-kernel@vger.kernel.org>,
lustre <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 04/19] staging: lustre: discard cfs_time_seconds()
Date: Tue, 9 Jan 2018 09:24:47 +0100 [thread overview]
Message-ID: <20180109082447.GA13112@kroah.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1801081708220.9942@casper.infradead.org>
On Mon, Jan 08, 2018 at 06:04:33PM +0000, James Simmons wrote:
>
> > On Mon, Jan 08, 2018 at 04:52:35PM +0000, James Simmons wrote:
> > >
> > > > cfs_time_seconds() converts a number of seconds to the
> > > > matching number of jiffies.
> > > > The standard way to do this in Linux is "* HZ".
> > > > So discard cfs_time_seconds() and use "* HZ" instead.
> > >
> > > Just to make you aware I have been working for several months on
> > > moving lustre away from using jiffies as much as possible. The
> > > problem with using HZ is that it can vary. So when you have a
> > > parallel file system with batches of nodes that have different
> > > values of HZ you can get very interesting corner cases. So I have
> > > been moving everything over to time64_t and ktime. Also I mostly
> > > have killed off the cfs_time_shift* and crap as well. You see all
> > > work under https://jira.hpdd.intel.com/browse/LU-9019. So many
> > > of the cases you did below don't event exist any more. I was
> > > planning to push those changes after the next merge window.
> >
> > First patch to me "wins", none of this "don't touch this code because
> > I'm going to work on it in the future" stuff. That has been documented
> > to kill contributions and in one case, a whole opensource kernel
> > project.
> >
> > So Neil's patches should be evaluated first, don't develop behind closed
> > walls like you are doing
>
> What I'm saying is my work had been tested and various bugs have
> been worked out before it gets to you. His work is new and untested. His
> work can be evaluated first but that doesn't mean it ready to land first.
> The wait event changes is a pretty big change that can have unseen
> consequences.
And how in the world am I supposed to know that your work is somehow
better than his? I don't see your work in my inbox at all, so am I
supposed to just guess?
Come on, you all know how kernel development works, and it sure isn't
this way.
> > I've merged almost all of them now, except for the ones that broke the
> > build :)
>
> He just posted a updated the version of the l_wait_event changes a few
> hours ago based on feed back. Please give it more than a few hours to
> bake. I like to test them to make sure things don't break. I hate to
> find out it breaks things and have it reverted. Please.
reverts are trivial, delaying patch acceptance for no good reason is
not.
thanks,
greg k-h
next prev parent reply other threads:[~2018-01-09 8:24 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 3:28 [lustre-devel] [PATCH 5 v2: 00/19] staging: lustre: use standard wait_event macros NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-08 3:28 ` [lustre-devel] [PATCH 13/19] staging: lustre: use wait_event_idle_timeout in ptlrpcd() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:34 ` [lustre-devel] " James Simmons
2018-01-17 15:34 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 07/19] staging: lustre: simplify l_wait_event when intr handler but no timeout NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:29 ` [lustre-devel] " James Simmons
2018-01-17 15:29 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 06/19] staging: lustre: introduce and use l_wait_event_abortable() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:30 ` [lustre-devel] " James Simmons
2018-01-17 15:30 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 12/19] staging: lustre: make polling loop in ptlrpc_unregister_bulk more obvious NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:33 ` [lustre-devel] " James Simmons
2018-01-17 15:33 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 01/19] sched/wait: add wait_event_idle() functions NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:26 ` [lustre-devel] " James Simmons
2018-01-17 15:26 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 17/19] staging: lustre: remove l_wait_event from ptlrpc_set_wait NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:36 ` [lustre-devel] " James Simmons
2018-01-17 15:36 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 15/19] staging: lustre: use explicit poll loop in ptlrpc_service_unlink_rqbd NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:35 ` [lustre-devel] " James Simmons
2018-01-17 15:35 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 05/19] staging: lustre: use wait_event_idle_timeout() where appropriate NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:27 ` [lustre-devel] " James Simmons
2018-01-17 15:27 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 03/19] staging: lustre: replace simple cases of l_wait_event() with wait_event() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:27 ` [lustre-devel] " James Simmons
2018-01-17 15:27 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 09/19] staging: lustre: open code polling loop instead of using l_wait_event() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:32 ` [lustre-devel] " James Simmons
2018-01-17 15:32 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 16/19] staging: lustre: use explicit poll loop in ptlrpc_unregister_reply NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:35 ` [lustre-devel] " James Simmons
2018-01-17 15:35 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 14/19] staging: lustre: improve waiting in sptlrpc_req_refresh_ctx NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:34 ` [lustre-devel] " James Simmons
2018-01-17 15:34 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 11/19] staging: lustre: remove back_to_sleep() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:33 ` [lustre-devel] " James Simmons
2018-01-17 15:33 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 10/19] staging: lustre: simplify waiting in ptlrpc_invalidate_import() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:32 ` [lustre-devel] " James Simmons
2018-01-17 15:32 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 02/19] staging: lustre: discard SVC_SIGNAL and related functions NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:26 ` [lustre-devel] " James Simmons
2018-01-17 15:26 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 04/19] staging: lustre: discard cfs_time_seconds() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-08 16:52 ` [lustre-devel] " James Simmons
2018-01-08 16:52 ` James Simmons
2018-01-08 17:00 ` [lustre-devel] " Greg Kroah-Hartman
2018-01-08 17:00 ` Greg Kroah-Hartman
2018-01-08 18:04 ` [lustre-devel] " James Simmons
2018-01-08 18:04 ` James Simmons
2018-01-09 8:24 ` Greg Kroah-Hartman [this message]
2018-01-09 8:24 ` Greg Kroah-Hartman
2018-01-17 15:29 ` [lustre-devel] " James Simmons
2018-01-17 15:29 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 08/19] staging: lustre: simplify waiting in ldlm_completion_ast() NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:31 ` [lustre-devel] " James Simmons
2018-01-17 15:31 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 19/19] staging: lustre: remove l_wait_event() and related code NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:36 ` [lustre-devel] " James Simmons
2018-01-17 15:36 ` James Simmons
2018-01-08 3:28 ` [lustre-devel] [PATCH 18/19] staging: lustre: replace l_wait_event_exclusive_head() with wait_event_idle_exclusive NeilBrown
2018-01-08 3:28 ` NeilBrown
2018-01-17 15:36 ` [lustre-devel] " James Simmons
2018-01-17 15:36 ` James Simmons
2018-01-08 14:59 ` [lustre-devel] [PATCH 5 v2: 00/19] staging: lustre: use standard wait_event macros Greg Kroah-Hartman
2018-01-08 14:59 ` Greg Kroah-Hartman
2018-01-08 16:21 ` [lustre-devel] " James Simmons
2018-01-08 16:21 ` James Simmons
2018-01-08 16:36 ` [lustre-devel] " Greg Kroah-Hartman
2018-01-08 16:36 ` Greg Kroah-Hartman
2018-01-08 18:06 ` [lustre-devel] " James Simmons
2018-01-08 18:06 ` James Simmons
2018-01-09 8:25 ` [lustre-devel] " Greg Kroah-Hartman
2018-01-09 8:25 ` Greg Kroah-Hartman
2018-01-09 1:44 ` [lustre-devel] " NeilBrown
2018-01-09 1:44 ` NeilBrown
2018-02-07 21:31 ` [lustre-devel] testing lustre NeilBrown
2018-02-08 9:42 ` Благодаренко Артём
2018-02-09 1:03 ` NeilBrown
2018-02-09 8:51 ` Благодаренко Артём
2018-02-09 23:52 ` NeilBrown
2018-02-10 3:51 ` Oleg Drokin
2018-02-12 1:05 ` NeilBrown
2018-02-10 23:07 ` James Simmons
2018-01-17 15:24 ` [lustre-devel] [PATCH 5 v2: 00/19] staging: lustre: use standard wait_event macros James Simmons
2018-01-17 15:24 ` James Simmons
-- strict thread matches above, loose matches on Subject: below --
2018-02-12 21:22 [lustre-devel] [PATCH 00/19] RESEND " NeilBrown
2018-02-12 21:22 ` [lustre-devel] [PATCH 04/19] staging: lustre: discard cfs_time_seconds() NeilBrown
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=20180109082447.GA13112@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andreas.dilger@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.