[lustre-devel] [PATCH 04/19] staging: lustre: discard cfs_time_seconds()

Greg Kroah-Hartman gregkh at linuxfoundation.org
Tue Jan 9 00:24:47 PST 2018

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


greg k-h

More information about the lustre-devel mailing list