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, KAMEZAWA Hiroyuki wrote:

> > 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.
> 

Thank you for very much for taking the time to look through each 
individual patch and suggest a different order.  If the ordering of the 
patches will help move us forward, then I'd be extremely happy to do it :)

> 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.
> 

I'll reorganize the patchset itself without any implementation changes so 
it flows better and is more appropriately seperated as you suggest.  I 
still believe there is no -rc material within this series (implying there 
is no -stable material either), but if you believe so then please reply to 
those patches with the new posting so Andrew can consider pushing it to 
Linus.

Thanks 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]