lkml.org 
[lkml]   [2016]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 00/14] Present useful limits to user (v2)
From
Date
On 2016-07-15 16:54, H. Peter Anvin wrote:
> On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@infradead.org> wrote:
>> On Fri, Jul 15, 2016 at 01:52:48PM +0000, Topi Miettinen wrote:
>>> On 07/15/16 12:43, Peter Zijlstra wrote:
>>>> On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
>>>>> Hello,
>>>>>
>>>>> There are many basic ways to control processes, including
>> capabilities,
>>>>> cgroups and resource limits. However, there are far fewer ways to
>> find out
>>>>> useful values for the limits, except blind trial and error.
>>>>>
>>>>> This patch series attempts to fix that by giving at least a nice
>> starting
>>>>> point from the highwater mark values of the resources in question.
>>>>> I looked where each limit is checked and added a call to update
>> the mark
>>>>> nearby.
>>>>
>>>> And how is that useful? Setting things to the high watermark is
>>>> basically the same as not setting the limit at all.
>>>
>>> What else would you use, too small limits?
>>
>> That question doesn't make sense.
>>
>> What's the point of setting a limit if it ends up being the same as
>> no-limit (aka unlimited).
>>
>> If you cannot explain; and you have not so far; what use these values
>> are, why would we look at the patches.
>
> One reason is to catch a malfunctioning process rather than dragging the whole system down with it. It could also be useful for development.
>
Additionally, there are quite a few applications which don't gracefully
handle memory allocation or process creation failures, either hanging,
constantly retrying, or just dying when this happens. For such an
application, you have to set the limit to the high watermark if you want
them limited at all, otherwise they don't work. A classic example of
this is the official client for Dropbox. If it can't start up all the
insane number of threads it thinks it needs, then it just hangs.
However, it's also a network service, and therefore is a reasonable
target for hackers, so it makes sense to try and limit it. I've run
into similar issues with quite a few 'desktop' services, both open and
closed source.

Looking at this another way, this is most useful for things that have a
deterministic maximum resource usage under regular use, not something
like a forking server which has a functionally unbounded maximum
resource usage.

\
 
 \ /
  Last update: 2016-07-18 15:41    [W:0.031 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site