On Wed, Jun 02, 2010 at 02:49:49AM -0700, David Rientjes wrote: > 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. Well there are a large number of patches with no objections, some of which are bug-fixes which may need to be backported to earlier kernels. It would be nice if the patchset would be rearranged so all these can be merged soon (I don't want the situation where a couple of patches hold up your entire patchset again). When you are reduced to a few patches changing major functionality, it could be eaiser to get those reviewed and merged on their own. > 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. Well the merge window is closed and even if it wasn't the patches would be better to sit in -mm for a bit. So I don't think there is a big rush now, let's just get it right so everything is lined up to get into the next merge window. -- 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>