<lizefan@xxxxxxxxxx>,Johannes Weiner <hannes@xxxxxxxxxxx>,Alexei Starovoitov <ast@xxxxxxxxxx>,Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>,Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>,Balbir Singh <bsingharora@xxxxxxxxx>,Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>,"David S. Miller" <davem@xxxxxxxxxxxxx>,Nicolas Dichtel <nicolas.dichtel@xxxxxxxxx>,Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,Konstantin Khlebnikov <koct9i@xxxxxxxxx>,Jiri Slaby <jslaby@xxxxxxx>,Cyrill Gorcunov <gorcunov@xxxxxxxxxx>,Michal Hocko <mhocko@xxxxxxxx>,Vlastimil Babka <vbabka@xxxxxxx>,Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>,Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>,Dan Carpenter <dan.carpenter@xxxxxxxxxx>,Michael Kerrisk <mtk.manpages@xxxxxxxxx>,"Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>,Marcus Gelderie <redmnic@xxxxxxxxx>,Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>,Joe Perches <joe@xxxxxxxxxxx>,Frederic Weisbecker <fweisbec@xxxxxxxxx>,Andrea Arcangeli <aarcange@xxxxxxxxxx>,! "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>,Andi Kleen <ak@xxxxxxxxxxxxxxx>,Oleg Nesterov <oleg@xxxxxxxxxx>,Stas Sergeev <stsp@xxxxxxx>,Amanieu d'Antras <amanieu@xxxxxxxxx>,Richard Weinberger <richard@xxxxxx>,Wang Xiaoqiang <wangxq10@xxxxxxxxxx>,Helge Deller <deller@xxxxxx>,Mateusz Guzik <mguzik@xxxxxxxxxx>,Alex Thorlton <athorlton@xxxxxxx>,Ben Segall <bsegall@xxxxxxxxxx>,John Stultz <john.stultz@xxxxxxxxxx>,Rik van Riel <riel@xxxxxxxxxx>,Eric B Munson <emunson@xxxxxxxxxx>,Alexey Klimov <klimov.linux@xxxxxxxxx>,Chen Gang <gang.chen.5i5j@xxxxxxxxx>,Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>,David Rientjes <rientjes@xxxxxxxxxx>,Hugh Dickins <hughd@xxxxxxxxxx>,Alexander Kuleshov <kuleshovmail@xxxxxxxxx>,"open list:DOCUMENTATION" <linux-doc@xxxxxxxxxxxxxxx>,"open list:IA64 (Itanium) PLATFORM" <linux-ia64@xxxxxxxxxxxxxxx>,"open list:KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC" <kvm-ppc@xxxxxxxxxxxxxxx>,"open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@xxxxxxxxxxxxxxx>,"open list:LINUX FOR POWERPC! (32-BIT AND 64-BIT)" <linuxppc-dev@xxxxxxxxxxxxxxxx>,"open list:INFINIBAND SUBSYSTEM" <linux-rdma@xxxxxxxxxxxxxxx>,"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@xxxxxxxxxxxxxxx>,"open list:CONTROL GROUP (CGROUP)" <cgroups@xxxxxxxxxxxxxxx>,"open list:BPF (Safe dynamic programs and tools)" <netdev@xxxxxxxxxxxxxxx>,"open list:MEMORY MANAGEMENT" <linux-mm@xxxxxxxxx> Message-ID: <D79806FE-E6B9-481B-8AA2-A1800419D9B5@xxxxxxxxx> On July 15, 2016 6:59:56 AM PDT, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
