On Thu, 16 Sep 2010, KOSAKI Motohiro wrote: > Current oom_score_adj is completely broken because It is strongly bound > google usecase and ignore other all. > We've talked about this issue three times already. The last two times you've sent a revert patch, you failed to followup on the threads: http://marc.info/?t=128272938200002 http://marc.info/?t=128324705200002 And now you've gone above Andrew, who is the maintainer of this code, and straight to Linus. Between that and your failure to respond to my answers to your questions, I'm really stunned at how unprofessional you've handled this. I've responded to every one of your emails and I've described the power of oom_score_adj as it acts on a higher resolution than oom_adj (1/1000th of RAM), respects the dynamic nature of cgroups, provides a rough approximation to users of oom_adj, and an exact equivalent of polarizing users of oom_adj, which is by far the most common usecase. That feature, as is the entire oom killer rewrite, is not specific in any way to Google, which I've stated many times, yet you constantly insist that it's so. Yes, we deal with oom issues on scales you've never seen. And instead of carrying internal patches to fix it since oom_adj is _only_ useful for polarizing a task and not relative to others competing for the same resources, I reworked the entire heuristic from scratch since we're not the only ones who want a sane priority killing. We are not the only ones who add mems to cpusets, adjust memcg limits, add nodes to mempolicies, or use memory hotplug. oom_adj would require a new value whenever you did any of those for a static priority. The fact that you constantly ignore is that the amount of memory that an aggregate of tasks can access is _dynamic_ and so the kill priority will change unless we define it as a static value that has a unit as a proportion of available memory as oom_score_adj does. Nobody cares about static oom scores like you introduce here with the revert; static oom scores mean _nothing_ because they are only useful in comparison to other eligible tasks. You never respond to any of this, but you just keep pushing your same old revert. You never responded to my email to Andrew that showed how this isn't a regression, so I guess I can only ask Linus to read the same email since you're pushing it to him now (http://marc.info/?l=linux-mm&m=128393429131399). I really hope we can put this to rest because it's frankly getting old competing with a broken record. -- 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>