Re: [patch -mm 08/18] oom: badness heuristic rewrite

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 4 Jun 2010 08:53:47 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 3 Jun 2010 16:10:30 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Wed,  2 Jun 2010 22:54:03 +0900 (JST)
> > KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > 
> > > > Why?
> > > > 
> > > > If it's because the patch is too big, I've explained a few times that 
> > > > functionally you can't break it apart into anything meaningful.  I do not 
> > > > believe it is better to break functional changes into smaller patches that 
> > > > simply change function signatures to pass additional arguments that are 
> > > > unused in the first patch, for example.
> > > > 
> > > > If it's because it adds /proc/pid/oom_score_adj in the same patch, that's 
> > > > allowed since otherwise it would be useless with the old heuristic.  In 
> > > > other words, you cannot apply oom_score_adj's meaning to the bitshift in 
> > > > any sane way.
> > > > 
> > > > I'll suggest what I have multiple times: the easiest way to review the 
> > > > functional change here is to merge the patch into your own tree and then 
> > > > review oom_badness().  I agree that the way the diff comes out it is a 
> > > > little difficult to read just from the patch form, so merging it and 
> > > > reviewing the actual heuristic function is the easiest way.
> > > 
> > > I've already explained the reason. 1) all-of-rewrite patches are 
> > > always unacceptable. that's prevent our code maintainance.
> > 
> > No, we'll sometime completely replace implementations.  There's no hard
> > rule apart from "whatever makes sense".  If wholesale replacement makes
> > sense as a patch-presentation method then we'll do that.
> > 
> I agree. 
> 
> IMHO.
> 
> But this series includes both of bug fixes and new features at random.
> Then, a small bugfixes, which doens't require refactoring, seems to do that.
> That's irritating guys (at least me) because it seems that he tries to sneak
> his own new logic into bugfix and moreover, it makes backport to distro difficult.
> I'd like to beg him separate them into 2 series as bugfix and something new.
> 

Sure, bugfixes should come separately and first.  For a number of
reasons:

- people (including the -stable maintainers) might want to backport them

- we might end up not merging the larger, bugfix-including patches at all

- the large bugfix-including patches might blow up and need
  reverting.  If we do that, we accidentally revert bugfixes!

Have we identified specifically which bugfixes should be separated out
in this fashion?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>