On Feb 28, 2015 2:50 PM, "Tejun Heo" <t...@kernel.org> wrote: > > On Sat, Feb 28, 2015 at 02:26:58PM -0800, Tim Hockin wrote: > > Wow, so much anger. I'm not even sure how to respond, so I'll just > > say this and sign off. All I want is a better, friendlier, more > > useful system overall. We clearly have different ways of looking at > > the problem. > > Can you communicate anything w/o passive aggression? If you have a > technical point, just state that. Can you at least agree that we > shouldn't be making design decisions based on 16bit pid_t?
Hmm, I have screwed this thread up, I think. I've made some remarks that did not come through with the proper tongue-in-cheek slant. I'm not being passive aggressive - we DO look at this problem differently. OF COURSE we should not make decisions based on ancient artifacts of history. My point was that there are secondary considerations here - PIDs are more than just the memory that backs them. They _ARE_ a constrained resource, and you shouldn't assume the constraint is just physical memory. It is a piece of policy that is outside the control of the kernel proper - we handed those keys to userspace along time ago. Given that, I believe and have believed that the solution should model the problem as the user perceives it - limiting PIDs - rather than attaching to a solution-by-proxy. Yes a solution here partially overlaps with kmemcg, but I don't think that is a significant problem. They are different policies governing behavior that may result in the same condition, but for very different reasons. I do not think that is particularly bad for overall comprehension, and I think the fact that this popped up yet again indicates the existence of some nugget of user experience that is worth paying consideration to. I appreciate your promised consideration through a slightly refocused lens. I will go back to my cave and do something I hope is more productive and less antagonistic. I did not mean to bring out so much vitriol. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
