linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: "Daniel Phillips" <daniel@phunq.net>,
	"Lukáš Czerner" <lczerner@redhat.com>,
	"Pavel Machek" <pavel@ucw.cz>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [RFC] Tux3 for review
Date: Sun, 22 Jun 2014 11:06:00 +1000	[thread overview]
Message-ID: <20140622010600.GX9508@dastard> (raw)
In-Reply-To: <1403378941.2177.24.camel@dabdike.int.hansenpartnership.com>

On Sat, Jun 21, 2014 at 12:29:01PM -0700, James Bottomley wrote:
> On Thu, 2014-06-19 at 14:58 -0700, Daniel Phillips wrote:
> > On Thursday, June 19, 2014 2:26:48 AM PDT, Lukáš Czerner wrote:
> > > Let me remind you some more important problems Dave brought up,
> > > including page forking:
> > >
> > > "
> > >  The hacks around VFS and MM functionality need to have demonstrated
> > >  methods for being removed.
> > 
> > We already removed 450 lines of core kernel workarounds from Tux3 with an 
> > approach that was literally cut and pasted from one of Dave's emails. Then 
> > Dave changed his mind. Now the Tux3 team has been assigned a research 
> > project to improve core kernel writeback instead of simply adapting the 
> > approach that is already proven to work well enough. That is a rather 
> > blatant example of "perfect is the enemy of good enough". Please read the 
> > thread.
> 
> That's a bit disingenuous: the concern has always been how page forking
> interacted with writeback.  It's not new, it was one of the major things
> brought up at LSF 14 months ago, so you weren't just assigned this.

BTW, it's worth noting that reviewers are *allowed* to change their
mind at any time during a discussion or during review cycles.
Indeed, this occurs quite commonly. It's no different to multiple
reviewers disagreeing on what the best way to make the improvement
is - sometimes it takes an implementation to solidify opinion on the
best approach to solving a problem.

i.e. it took an implementation of the writeback hook tailored
specifically to tux3's requirements to understand the best way to
solve the infrastructure problem for *everyone*. This is how review
is supposed to work - take an idea, and refine it into something
better that works for everyone.

We'd have been stuck way up the creek without a paddle a long time
ago if reviewers weren't allowed to change their minds....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2014-06-22  1:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-17  0:50 [RFC] Tux3 for review Daniel Phillips
2014-05-17  5:09 ` Martin Steigerwald
2014-05-17  5:29   ` Daniel Phillips
2014-05-20  6:56     ` Daniel Phillips
2014-05-18 23:55 ` Dave Chinner
2014-05-20  0:55   ` Daniel Phillips
2014-05-20  3:18     ` Dave Chinner
2014-05-20  5:41       ` Daniel Phillips
2014-05-20 17:25         ` Daniel Phillips
2014-06-13 10:32       ` Pavel Machek
2014-06-13 17:49         ` Daniel Phillips
2014-06-13 20:20           ` Pavel Machek
2014-06-15 21:41             ` Daniel Phillips
2014-06-16 15:25               ` James Bottomley
2014-06-19  8:21                 ` Pavel Machek
2014-06-19  9:26                   ` Lukáš Czerner
2014-06-19 21:58                     ` Daniel Phillips
2014-06-21 19:29                       ` James Bottomley
2014-06-22  1:06                         ` Dave Chinner [this message]
2014-06-24 11:16                           ` Daniel Phillips
2014-06-22  3:32                         ` Daniel Phillips
2014-06-22 14:43                           ` James Bottomley
     [not found]                             ` <522aee97-34e7-4adc-adf2-c9b73aa0ef36@phunq.net>
2014-06-24  4:41                               ` James Bottomley
2014-06-24  9:10                                 ` Daniel Phillips
2014-06-24 10:59                                   ` Theodore Ts'o
2014-06-24 11:27                                     ` Daniel Phillips
2014-06-24 11:52                                       ` James Bottomley
2014-06-24 12:10                                         ` Daniel Phillips
2014-06-22 18:34                           ` Theodore Ts'o
2014-06-24  0:31                             ` Daniel Phillips
2014-06-24  0:19                         ` Daniel Phillips
2014-05-22  9:52     ` Dongsu Park
2014-05-23  8:21       ` Daniel Phillips
2014-06-19 16:24 ` Josef Bacik
2014-06-19 22:14   ` Daniel Phillips

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=20140622010600.GX9508@dastard \
    --to=david@fromorbit.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel@phunq.net \
    --cc=lczerner@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@linux-foundation.org \
    /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;
as well as URLs for NNTP newsgroup(s).