On Thu, 3 Jun 2010, KOSAKI Motohiro wrote: > > I would consider what I said above, "when faced with memory pressure from > > an out of control or memory hogging task on the desktop, the oom killer > > now kills it instead of a vital task such as an X server because of the > > use of the task's rss instead of total_vm statistic" as an improvement > > over killing X in those cases which it currently does. How do you > > disagree? > > People observed simple s/total_vm/rss/ patch solve X issue. It doesn't, you need to consider swap as well. > Then, > other additional pieces need to explain why that's necessary and > how to confirm it. > Are you talking about oom_score_adj? Please read the patch description. > In other word, I'm sure I'll continue to get OOM bug report in future. > I'll need to decide revert or not revert each patches. no infomation is > unwelcome. also, that's the reason why all of rewrite patch is wrong. > if it will be merged, small bug report eventually is going to make > all of revert. that doesn't fit our developerment process. > You're speculating that a new problem will be introduced with this change that you cannot describe but are concerned that you won't be able to debug that unknown issue without simply reverting the entire change? These "nack"ing reasons of yours are getting more and more interesting, I must say. -- 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>