On Mon, 1 Nov 2010, KOSAKI Motohiro wrote: > > The new tunable added in 2.6.36, /proc/pid/oom_score_adj, is necessary for > > the units that the badness score now uses. We need a tunable with a much > > Who we? > Linux users who care about prioritizing tasks for oom kill with a tunable that (1) has a unit, (2) has a higher resolution, and (3) is linear and not exponential. Memcg doesn't solve this issue without incurring a 1% memory cost. > > higher resolution than the oom_adj scale from -16 to +15, and one that > > scales linearly as opposed to exponentially. Since that tunable is much > > more powerful than the oom_adj implementation, which never made any real > > The reason that you ware NAKed was not to introduce new powerful feature. > It was caused to break old and used feature from applications. > No, it doesn't, and you completely and utterly failed to show a single usecase that broke as a result of this because nobody can currently use oom_adj for anything other than polarization. Thus, there's no backwards compatibility issue. > > sense for defining oom killing priority for any purpose other than > > polarization, the old tunable is deprecated for two years. > > You haven't tested your patch at all. Distro's initram script are using > oom_adj interface and latest kernel show pointless warnings > "/proc/xx/oom_adj is deprecated, please use /proc/xx/oom_score_adj instead." > at _every_ boot time. > Yes, I've tested it, and it deprecates the tunable as expected. A single warning message serves the purpose well: let users know one time without being overly verbose that the tunable is deprecated and give them sufficient time (2 years) to start using the new tunable. That's how deprecation is done. -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>