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
next prev parent 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).