All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Alexander Graf <agraf@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim Kr??m???? <rkrcmar@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Doug Ledford <dledford@redhat.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Christian Benvenuti <benve@cisco.com>,
	Dave Goodell <dgoodell@cisco.com>,
	Sudeep Dutt <sudeep.dutt@intel.com>Ashutosh Dixit <a>
Subject: Re: [PATCH 00/14] Present useful limits to user (v2)
Date: Fri, 15 Jul 2016 15:59:56 +0200	[thread overview]
Message-ID: <20160715135956.GA3115@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Alexander Graf <agraf@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim Kr??m???? <rkrcmar@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Doug Ledford <dledford@redhat.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Christian Benvenuti <benve@cisco.com>,
	Dave Goodell <dgoodell@cisco.com>,
	Sudeep Dutt <sudeep.dutt@intel.com>,
	Ashutosh Dixit <a
Subject: Re: [PATCH 00/14] Present useful limits to user (v2)
Date: Fri, 15 Jul 2016 15:59:56 +0200	[thread overview]
Message-ID: <20160715135956.GA3115@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Alexander Graf <agraf@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim Kr??m???? <rkrcmar@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Doug Ledford <dledford@redhat.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Christian Benvenuti <benve@cisco.com>,
	Dave Goodell <dgoodell@cisco.com>,
	Sudeep Dutt <sudeep.dutt@intel.com>,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Tejun Heo <tj@kernel.org>, Li Zefan <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>
Subject: Re: [PATCH 00/14] Present useful limits to user (v2)
Date: Fri, 15 Jul 2016 15:59:56 +0200	[thread overview]
Message-ID: <20160715135956.GA3115@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Alexander Graf <agraf@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim Kr??m???? <rkrcmar@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Doug Ledford <dledford@redhat.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Christian Benvenuti <benve@cisco.com>,
	Dave Goodell <dgoodell@cisco.com>,
	Sudeep Dutt <sudeep.dutt@intel.com>,
	Ashutosh Dixit <ashutosh.dixit@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Tejun Heo <tj@kernel.org>, Li Zefan <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>
Subject: Re: [PATCH 00/14] Present useful limits to user (v2)
Date: Fri, 15 Jul 2016 15:59:56 +0200	[thread overview]
Message-ID: <20160715135956.GA3115@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Alexander Graf <agraf@suse.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Radim Kr??m???? <rkrcmar@redhat.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Doug Ledford <dledford@redhat.com>,
	Sean Hefty <sean.hefty@intel.com>,
	Hal Rosenstock <hal.rosenstock@gmail.com>,
	Mike Marciniszyn <mike.marciniszyn@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Christian Benvenuti <benve@cisco.com>,
	Dave Goodell <dgoodell@cisco.com>,
	Sudeep Dutt <sudeep.dutt@intel.com>, Ashutosh Dixit <a>
Subject: Re: [PATCH 00/14] Present useful limits to user (v2)
Date: Fri, 15 Jul 2016 15:59:56 +0200	[thread overview]
Message-ID: <20160715135956.GA3115@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <28b4b919-4f50-d9f6-c5e1-d1e92ea1ba1c@gmail.com>

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-07-15 13:59 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 10:35 [PATCH 00/14] Present useful limits to user (v2) Topi Miettinen
2016-07-15 10:35 ` Topi Miettinen
2016-07-15 10:35 ` Topi Miettinen
2016-07-15 10:35 ` Topi Miettinen
2016-07-15 10:35 ` Topi Miettinen
2016-07-15 10:35 ` [PATCH 01/14] resource limits: foundation for resource highwater tracking Topi Miettinen
2016-07-15 12:12   ` kbuild test robot
2016-07-15 12:49   ` Nicolas Dichtel
2016-07-15 16:27     ` Topi Miettinen
2016-07-15 17:57       ` Nicolas Dichtel
2016-07-15 10:35 ` [PATCH 02/14] resource limits: aggregate task highwater marks to cgroup level Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 12:38   ` kbuild test robot
2016-07-15 14:10   ` Tejun Heo
2016-07-15 17:15     ` Topi Miettinen
2016-07-18 22:52       ` Tejun Heo
2016-07-19 16:57         ` Topi Miettinen
2016-07-19 18:18           ` Tejun Heo
2016-07-15 10:35 ` [PATCH 03/14] resource limits: track highwater mark of file sizes Topi Miettinen
2016-07-15 10:35 ` [PATCH 04/14] resource limits: track highwater mark of VM data segment Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 10:35 ` [PATCH 05/14] resource limits: track highwater mark of stack size Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 10:35 ` [PATCH 06/14] resource limits: track highwater mark of cores dumped Topi Miettinen
2016-07-15 10:35 ` [PATCH 07/14] resource limits: track highwater mark of user processes Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 10:35 ` [PATCH 08/14] resource limits: track highwater mark of number of files Topi Miettinen
2016-07-15 10:35 ` [PATCH 09/14] resource limits: track highwater mark of locked memory Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 15:14   ` Oleg Nesterov
2016-07-15 15:14     ` Oleg Nesterov
2016-07-15 15:14     ` Oleg Nesterov
2016-07-15 17:39     ` Topi Miettinen
2016-07-15 17:39       ` Topi Miettinen
2016-07-15 17:39       ` Topi Miettinen
2016-07-18 15:38       ` Oleg Nesterov
2016-07-18 15:38         ` Oleg Nesterov
2016-07-18 15:38         ` Oleg Nesterov
2016-07-15 17:45   ` Topi Miettinen
2016-07-15 10:35 ` [PATCH 10/14] resource limits: track highwater mark of address space size Topi Miettinen
2016-07-15 10:35   ` Topi Miettinen
2016-07-15 10:35 ` [PATCH 11/14] resource limits: track highwater mark of number of pending signals Topi Miettinen
2016-07-15 10:35 ` [PATCH 12/14] resource limits: track highwater mark of size of message queues Topi Miettinen
2016-07-15 10:36 ` [PATCH 13/14] resource limits: track highwater mark of niceness Topi Miettinen
2016-07-15 10:36 ` [PATCH 14/14] resource limits: track highwater mark of RT priority Topi Miettinen
2016-07-15 12:43 ` [PATCH 00/14] Present useful limits to user (v2) Peter Zijlstra
2016-07-15 12:43   ` Peter Zijlstra
2016-07-15 12:43   ` Peter Zijlstra
2016-07-15 13:52   ` Topi Miettinen
2016-07-15 13:52     ` Topi Miettinen
2016-07-15 13:52     ` Topi Miettinen
2016-07-15 13:59     ` Peter Zijlstra [this message]
2016-07-15 13:59       ` Peter Zijlstra
2016-07-15 13:59       ` Peter Zijlstra
2016-07-15 13:59       ` Peter Zijlstra
2016-07-15 13:59       ` Peter Zijlstra
2016-07-15 16:57       ` Topi Miettinen
2016-07-15 16:57         ` Topi Miettinen
2016-07-15 16:57         ` Topi Miettinen
2016-07-15 16:57         ` Topi Miettinen
2016-07-15 20:54       ` H. Peter Anvin
2016-07-15 20:54       ` H. Peter Anvin
2016-07-15 20:54         ` H. Peter Anvin
2016-07-15 20:54         ` H. Peter Anvin
2016-07-15 20:54         ` H. Peter Anvin
2016-07-18 13:00         ` Austin S. Hemmelgarn
     [not found]       ` <20160715135956.GA3115-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
2016-07-15 20:54         ` H. Peter Anvin
2016-07-15 20:54         ` H. Peter Anvin
2016-07-15 20:54       ` H. Peter Anvin
2016-07-15 20:54       ` H. Peter Anvin
2016-07-15 13:04 ` Balbir Singh
2016-07-15 13:04   ` Balbir Singh
2016-07-15 13:04   ` Balbir Singh
2016-07-15 16:35   ` Topi Miettinen
2016-07-15 16:35     ` Topi Miettinen
2016-07-15 16:35     ` Topi Miettinen
2016-07-18 22:05     ` Doug Ledford
2016-07-18 22:05       ` Doug Ledford
2016-07-19 16:53       ` Topi Miettinen
2016-07-19 16:53         ` Topi Miettinen
2016-07-19 16:53         ` Topi Miettinen
2016-07-15 14:19 ` Richard Weinberger
2016-07-15 14:19   ` Richard Weinberger
2016-07-15 14:19   ` Richard Weinberger
2016-07-15 17:19   ` Topi Miettinen
2016-07-15 17:19     ` Topi Miettinen
2016-07-15 17:19     ` Topi Miettinen
2016-07-18 21:25   ` Doug Ledford
2016-07-18 21:25     ` Doug Ledford
2016-07-15 17:42 ` Topi Miettinen
2016-08-03 18:20 ` Topi Miettinen
2016-08-03 18:20   ` Topi Miettinen
2016-08-04  6:59   ` Fwd: " Topi Miettinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160715135956.GA3115@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=agraf@suse.com \
    --cc=benh@kernel.crashing.org \
    --cc=benve@cisco.com \
    --cc=corbet@lwn.net \
    --cc=dennis.dalessandro@intel.com \
    --cc=dgoodell@cisco.com \
    --cc=dledford@redhat.com \
    --cc=fenghua.yu@intel.com \
    --cc=hal.rosenstock@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.marciniszyn@intel.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.hefty@intel.com \
    --cc=sudeep.dutt@intel.com \
    --cc=tglx@linutronix.de \
    --cc=toiwoton@gmail.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.