lkml.org 
[lkml]   [2015]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC 0/2] add nproc cgroup subsystem
On Sat, Feb 28, 2015 at 02:26:58PM -0800, Tim Hockin wrote:
> On Sat, Feb 28, 2015 at 8:57 AM, Tejun Heo <tj@kernel.org> wrote:
> >
> > On Sat, Feb 28, 2015 at 08:48:12AM -0800, Tim Hockin wrote:
> > > I am sorry that real-user problems are not perceived as substantial. This
> > > was/is a real issue for us. Being in limbo for years on end might not be a
> > > technical point, but I do think it matters, and that was my point.
> >
> > It's a problem which is localized to you and caused by the specific
> > problems of your setup. This isn't a wide-spread problem at all and
> > the world doesn't revolve around you. If your setup is so messed up
> > as to require sticking to 16bit pids, handle that locally. If
> > something at larger scale eases that handling, you get lucky. If not,
> > it's *your* predicament to deal with. The rest of the world doesn't
> > exist to wipe your ass.
>
> Wow, so much anger.

Yeah, quite surprising after such an intellectually honest discussion:

: On Fri, Feb 27, 2015 at 01:45:09PM -0800, Tim Hockin wrote:
: > At least 3 or 4 people have INDEPENDENTLY decided this is what is
: > causing them pain and tried to fix it and invested the time to send a
: > patch says that it is actually a thing. There exists a problem that
: > you are disallowing to be fixed. Do you recognize that users are
: > experiencing pain? Why do you hate your users? :)

[...]

: > Are you willing to put a drop-dead date on it? If we don't have
: > kmemcg working well enough to _actually_ bound PID usage and FD usage
: > by, say, June 1st, will you then accept a patch to this effect? If
: > the answer is no, then I have zero faith that it's coming any time
: > soon - I heard this 2 years ago. I believed you then.

> 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.

Overlapping features and inconsistent userspace interfaces are only
better for the people that pick the hacks. They are the opposite of
friendly and useful. They are also horrible to maintain, which could
be a reason why you constantly disagree with the people that cleaned
up this unholy mess and are now trying to keep a balance between your
short term interests and the long-term health of the Linux kernel.


\
 
 \ /
  Last update: 2015-03-01 00:21    [W:0.084 / U:1.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site