Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1444592 > unrolled thread

Re: [PATCH 00/14] Present useful limits to user (v2)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 00/14] Present useful limits to user (v2) "H. Peter Anvin" <hpa@zytor.com> - 2016-07-15 23:10 +0200
    Re: [PATCH 00/14] Present useful limits to user (v2) "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-07-18 15:10 +0200

#1444592 — Re: [PATCH 00/14] Present useful limits to user (v2)

<lizefan@huawei.com>,Johannes Weiner <hannes@cmpxchg.org>,Alexei Starovoitov <ast@kernel.org>,Arnaldo Carvalho de Melo <acme@kernel.org>,Alexander Shishkin <alexander.shishkin@linux.intel.com>,Balbir Singh <bsingharora@gmail.com>,Markus Elfring <elfring@users.sourceforge.net>,"David S. Miller" <davem@davemloft.net>,Nicolas Dichtel <nicolas.dichtel@6wind.com>,Andrew Morton <akpm@linux-foundation.org>,Konstantin Khlebnikov <koct9i@gmail.com>,Jiri Slaby <jslaby@suse.cz>,Cyrill Gorcunov <gorcunov@openvz.org>,Michal Hocko <mhocko@suse.com>,Vlastimil Babka <vbabka@suse.cz>,Dave Hansen <dave.hansen@linux.intel.com>,Greg Kroah-Hartman <gregkh@linuxfoundation.org>,Dan Carpenter <dan.carpenter@oracle.com>,Michael Kerrisk <mtk.manpages@gmail.com>,"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,Marcus Gelderie <redmnic@gmail.com>,Vladimir Davydov <vdavydov@virtuozzo.com>,Joe Perches <joe@perches.com>,Frederic Weisbecker <fweisbec@gmail.com>,Andrea Arcangeli <aarcange@redhat.com>,!
 "Eric W.
Biederman" <ebiederm@xmission.com>,Andi Kleen <ak@linux.intel.com>,Oleg Nesterov <oleg@redhat.com>,Stas Sergeev <stsp@list.ru>,Amanieu d'Antras <amanieu@gmail.com>,Richard Weinberger <richard@nod.at>,Wang Xiaoqiang <wangxq10@lzu.edu.cn>,Helge Deller <deller@gmx.de>,Mateusz Guzik <mguzik@redhat.com>,Alex Thorlton <athorlton@sgi.com>,Ben Segall <bsegall@google.com>,John Stultz <john.stultz@linaro.org>,Rik van Riel <riel@redhat.com>,Eric B Munson <emunson@akamai.com>,Alexey Klimov <klimov.linux@gmail.com>,Chen Gang <gang.chen.5i5j@gmail.com>,Andrey Ryabinin <aryabinin@virtuozzo.com>,David Rientjes <rientjes@google.com>,Hugh Dickins <hughd@google.com>,Alexander Kuleshov <kuleshovmail@gmail.com>,"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-ia64@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@vger.kernel.org>,"open list:LINUX FOR POWERPC!
  (32-BIT
AND 64-BIT)" <linuxppc-dev@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>
Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@zytor.com>

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.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [next] | [standalone]

#1445470

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web