> > > process with CAP_SYS_RESOURCE capibility which have system resource > > > limits, like journaling resource on ext3/4 filesystem, RTC clock. so it > > > also the same treatment as process with CAP_SYS_ADMIN. > > > > > > > NACK, there's no justification that these tasks should be given a 3% > > memory bonus in the oom killer heuristic; in fact, since they can allocate > > without limits it is more important to target these tasks if they are > > using an egregious amount of memory. > > David, Stupid are YOU. you removed CAP_SYS_RESOURCE condition with ZERO > explanation and Figo reported a regression. That's enough the reason to > undo. YOU have a guilty to explain why do you want to change and why > do you think it has justification. > > Don't blame bug reporter. That's completely wrong. Can people stop throwing things at each other and worry about the facts - If it's a regression it should get reverted or fixed. But is it actually a regression ? Has the underlying behaviour changed in a problematic way? "CAP_SYS_RESOURCE threads have the ability to lower their own oom_score_adj values, thus, they should protect themselves if necessary like everything else." The reverse can be argued equally - that they can unprotect themselves if necessary. In fact it seems to be a "point of view" sort of question which way you deal with CAP_SYS_RESOURCE, and that to me argues that changing from old expected behaviour to a new behaviour is a regression. -- 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>