<lize...@huawei.com>,Johannes Weiner <han...@cmpxchg.org>,Alexei Starovoitov <a...@kernel.org>,Arnaldo Carvalho de Melo <a...@kernel.org>,Alexander Shishkin <alexander.shish...@linux.intel.com>,Balbir Singh <bsinghar...@gmail.com>,Markus Elfring <elfr...@users.sourceforge.net>,"David S. Miller" <da...@davemloft.net>,Nicolas Dichtel <nicolas.dich...@6wind.com>,Andrew Morton <a...@linux-foundation.org>,Konstantin Khlebnikov <koc...@gmail.com>,Jiri Slaby <jsl...@suse.cz>,Cyrill Gorcunov <gorcu...@openvz.org>,Michal Hocko <mho...@suse.com>,Vlastimil Babka <vba...@suse.cz>,Dave Hansen <dave.han...@linux.intel.com>,Greg Kroah-Hartman <gre...@linuxfoundation.org>,Dan Carpenter <dan.carpen...@oracle.com>,Michael Kerrisk <mtk.manpa...@gmail.com>,"Kirill A. Shutemov" <kirill.shute...@linux.intel.com>,Marcus Gelderie <redm...@gmail.com>,Vladimir Davydov <vdavy...@virtuozzo.com>,Joe Perches <j...@perches.com>,Frederic Weisbecker <fweis...@gmail.com>,Andrea Arcangeli <aarca...@redhat.com>,! "Eric W. Biederman" <ebied...@xmission.com>,Andi Kleen <a...@linux.intel.com>,Oleg Nesterov <o...@redhat.com>,Stas Sergeev <s...@list.ru>,Amanieu d'Antras <aman...@gmail.com>,Richard Weinberger <rich...@nod.at>,Wang Xiaoqiang <wangx...@lzu.edu.cn>,Helge Deller <del...@gmx.de>,Mateusz Guzik <mgu...@redhat.com>,Alex Thorlton <athorl...@sgi.com>,Ben Segall <bseg...@google.com>,John Stultz <john.stu...@linaro.org>,Rik van Riel <r...@redhat.com>,Eric B Munson <emun...@akamai.com>,Alexey Klimov <klimov.li...@gmail.com>,Chen Gang <gang.chen.5...@gmail.com>,Andrey Ryabinin <aryabi...@virtuozzo.com>,David Rientjes <rient...@google.com>,Hugh Dickins <hu...@google.com>,Alexander Kuleshov <kuleshovm...@gmail.com>,"open list:DOCUMENTATION" <linux-...@vger.kernel.org>,"open list:IA64 (Itanium) PLATFORM" <linux-i...@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-...@vger.kernel.org>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <k...@vger.kernel.org>,"open list:LINUX FOR POWERPC! (32-BIT AND 64-BIT)" <linuxppc-...@lists.ozlabs.org>,"open list:INFINIBAND SUBSYSTEM" <linux-r...@vger.kernel.org>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsde...@vger.kernel.org>,"open list:CONTROL GROUP (CGROUP)" <cgro...@vger.kernel.org>,"open list:BPF (Safe dynamic programs and tools)" <netdev@vger.kernel.org>,"open list:MEMORY MANAGEMENT" <linux...@kvack.org> Message-ID: <d79806fe-e6b9-481b-8aa2-a1800419d...@zytor.com>
On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <pet...@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.
