Re: [patch -mm 13/18] oom: avoid race for oom killed tasks detaching mm prior to exit

[David Rientjes <rientjes@google.com>]

On Wed, 2 Jun 2010, KAMEZAWA Hiroyuki wrote:

> > > No, it applies to mmotm-2010-05-21-16-05 as all of these patches do. I
> > > know you've pushed Oleg's patches
> > 
> > (plus other fixes)
> > 
> > > but they are also included here so no
> > > respin is necessary unless they are merged first (and I think that should
> > > only happen if Andrew considers them to be rc material).
> > 
> > Well, I disagree.
> > 
> > I think it is always better to push the simple bugfixes first, then
> > change/improve the logic.
> > 
> yes..yes...I hope David finish easy-to-be-merged ones and go to new stage.
> IOW, please reduce size of patches sent at once.
> 

How do you define "easy-to-be-merged"?  We've been through several 
iterations of this patchset where the end result is that it's been merged 
in -mm once, removed from -mm six weeks later, and nobody providing any 
feedback that I can work from.  Providing simple "nack" emails does 
nothing for the development of the patchset unless you actively get 
involved in the review process and subsequent discussion on how to move 
forward.

Listen, I want to hear everybody's ideas and suggestions on improvements.  
In fact, I think I've responded in a way that demonstrates that quite 
well: I've dropped the consolidation of sysctls, I've avoided deprecation 
of existing sysctls, I've unified the semantics of panic_on_oom, and I've 
split out patches where possible.  All of those were at the requests of 
people whom I've asked to review this patchset time and time again.

Kame, you've been very helpful in your feedback with regards to this 
patchset and I've valued your feedback from the first revision.  We had 
some differing views of how to handle task selection early on in other 
threads, but I sincerely enjoy hearing your feedback because it's 
interesting and challenging; you find things that I've missed and 
challenge me to defend decisions that were made.  I really, really like 
doing that type of development, I just wish we all could make some forward 
progress on this thing instead of staling out all the time.

I'm asking everyone to please review this work and comment on what you 
don't like or provide suggestions on how to improve it.  It's been posted 
in its various forms about eight times now over the course of a few 
months, I really hope there's no big surprises in it to anyone anymore.  
Sure, there are cleanups here that possibly could be considered rc 
material even though they admittedly aren't critical, but that isn't a 
reason to just stall out all of this work.  I'm sure Andrew can decide 
what he wants to merge into 2.6.35-rc2 after looking at the discussion and 
analyzing the impact; let us please focus on the actual implementation and 
design choices of the new oom killer presented here rather than get 
sidetracked.

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