On Tue, 6 Apr 2010, KOSAKI Motohiro wrote: > Many people reviewed these patches, but following four patches got no ack. > > oom-badness-heuristic-rewrite.patch Do you have any specific feedback that you could offer on why you decided to nack this? > oom-default-to-killing-current-for-pagefault-ooms.patch Same, what is the specific concern that you have with this patch? If you don't believe we should kill current first, could you please submit patches for all other architectures like powerpc that already do this as their only course of action for VM_FAULT_OOM and then make pagefault oom killing consistent amongst architectures? > oom-deprecate-oom_adj-tunable.patch Alan had a concern about removing /proc/pid/oom_adj, or redefining it with different semantics as I originally did, and then I updated the patchset to deprecate the old tunable as Andrew suggested. My somewhat arbitrary time of removal was approximately 18 months from the date of deprecation which would give us 5-6 major kernel releases in between. If you think that's too early of a deadline, then I'd happily extend it by 6 months or a year. Keeping /proc/pid/oom_adj around indefinitely isn't very helpful if there's a finer grained alternative available already unless you want /proc/pid/oom_adj to actually mean something in which case you'll never be able to seperate oom badness scores from bitshifts. I believe everyone agrees that a more understood and finer grained tunable is necessary as compared to the current implementation that has very limited functionality other than polarizing tasks. > oom-replace-sysctls-with-quick-mode.patch > > IIRC, alan and nick and I NAKed such patch. everybody explained the reason. Which patch of the four you listed are you referring to here? > We don't hope join loudly voice contest nor help to making flame. but it > doesn't mean explicit ack. > If someone has a concern with a patch and then I reply to it and the reply goes unanswered, what exactly does that imply? Do we want to stop development because discussion occurred on a patch yet no rebuttal was made that addressed specific points that I raised? Arguing to keep /proc/pid/oom_kill_allocating_task means that we should also not enable /proc/pid/oom_dump_tasks by default since the same systems that use the former will need to now disable the latter to avoid costly tasklist scans. So are you suggesting that we should not enable oom_dump_tasks like the rewrite does even though it provides very useful information to 99.9% (or perhaps 100%) of users to understand the memory usage of their tasks because you believe systems out there would flake out with the tasklist scan it requires, even though you can't cite a single example? Now instead of not replying to these questions and insisting that your nack stand based solely on the fact that you nacked it, please get involved in the development process. -- 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>