From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751810AbcGRNBC (ORCPT ); Mon, 18 Jul 2016 09:01:02 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:35936 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751689AbcGRNA6 (ORCPT ); Mon, 18 Jul 2016 09:00:58 -0400 Subject: Re: [PATCH 00/14] Present useful limits to user (v2) To: "H. Peter Anvin" , Peter Zijlstra , Topi Miettinen References: <1468578983-28229-1-git-send-email-toiwoton@gmail.com> <20160715124330.GR30154@twins.programming.kicks-ass.net> <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com> <20160715135956.GA3115@twins.programming.kicks-ass.net> <201607152054.u6FKslD1005327@mail.zytor.com> Cc: linux-kernel@vger.kernel.org, Jonathan Corbet , Tony Luck , Fenghua Yu , Alexander Graf , Paolo Bonzini , Radim Kr??m???? , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Thomas Gleixner , Ingo Molnar , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Doug Ledford , Sean Hefty , Hal Rosenstock , Mike Marciniszyn , Dennis Dalessandro , Christian Benvenuti , Dave Goodell , Sudeep Dutt , Ashutosh Dixit , Alex Williamson , Alexander Viro , Tejun Heo , Li.Zefan@zytor.com From: "Austin S. Hemmelgarn" Message-ID: <7072ea25-851e-aa8d-69d8-63e10faf6a40@gmail.com> Date: Mon, 18 Jul 2016 09:00:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <201607152054.u6FKslD1005327@mail.zytor.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-07-15 16:54, H. Peter Anvin wrote: > On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra 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.