On Tue, 6 Apr 2010 14:47:58 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> wrote: > 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? > I like this patch. But I think no one can't Ack this because there is no "correct" answer. At least, this show good behavior on my environment. > > oom-default-to-killing-current-for-pagefault-ooms.patch > > Same, what is the specific concern that you have with this patch? > I'm not sure about this. Personally, I feel pagefault-out-of-memory only happens drivers are corrupted. So, I have no much concern on this. > 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. > If oom-badness-heuristic-rewrite.patch will go ahead, this should go. But my concern is administorator has to check all oom_score_adj and tune it again if he adds more memory to the system. Now, not-small amount of people use Virtual Machine or Contaienr. So, this oom_score_adj's sensivity to the size of memory can put admins to hell. Assume a host A and B. A has 4G memory, B has 8G memory. Here, an applicaton which consumes 2G memory. Then, this application's oom_score will be 500 on A, 250 on B. To make oom_score 0 by oom_score_adj, admin should set -500 on A, -250 on B. I think this kind of interface is _bad_. If admin is great and all machines in the system has the same configuration, this oom_score_adj will work powerfully. I admit it. But usually, admin are not great and the system includes irregular hosts. I hope you add one more magic knob to give admins to show importance of application independent from system configuration, which can work cooperatively with oom_score_adj. > > 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? > replacing used sysctl is bad idea, in general. I have no _strong_ opinion. I welcome the patch series. But aboves are my concern. Thank you for your work. Regards, -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>