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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 4 Jun 2010 09:20:47 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:

> On Thu, 3 Jun 2010 17:04:43 -0700
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > 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?
> > 
> 
> In my personal observation
> 
>  [1/18]  for better behavior under cpuset.
>  [2/18]  for better behavior under cpuset.
>  [3/18]  for better behavior under mempolicy.
>  [4/18]  refactoring.
>  [5/18]  refactoring.
>  [6/18]  clean up.
>  [7/18]  changing the deault sysctl value.
>  [8/18]  completely new logic.
>  [9/18]  completely new logic.
>  [10/18] a supplement for 8,9.
>  [11/18] for better behavior under lowmem oom (disable oom kill)
>  [12/18] clean up
>  [13/18] bugfix for a possible race condition. (I'm not sure about details)
>  [14/18] bugfix
>  [15/18] bugfix
>  [16/18] bugfix
>  [17/18] bugfix
>  [18/18] clean up.
> 
> If distro admins are aggresive, them may backport 1,2,3,7,11 but
> it changes current logic. So, it's distro's decision.
> 

IMHO, without considering HUNKs, the patch order should be

  13,14,15,16,17,1,2,3,7,11,4,5,6,18,12,8,9,10.

bugfix -> patches for things making better -> refactoring -> the new implementation.

David, I have no objections to functions itself. But please start from small
good things. "Refactoring" is good but it tend to make backporting
not-straightforward. So, I think it should be done when there is no known issues.
I think you can do.

Bye,
-Kame


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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]