[Sorry to jump in that late]
On Tue 20-11-12 10:02:45, David Rientjes wrote:
> On Mon, 19 Nov 2012, Glauber Costa wrote:
>
> > >> In the case I outlined below, for backwards compatibility. What I
> > >> actually mean is that memcg *currently* allows arbitrary notifications.
> > >> One way to
[Sorry to jump in that late]
On Tue 20-11-12 10:02:45, David Rientjes wrote:
On Mon, 19 Nov 2012, Glauber Costa wrote:
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications.
One way to merge those,
-Original Message-
From: ext Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: 21 November, 2012 11:31
...
BTW, there's interface for OOM notification in memcg. See oom_control.
I guess other pressure levels can also fit to the interface.
---
Hi,
I have tracking this conversation
-Original Message-
From: ext Glauber Costa [mailto:glom...@parallels.com]
Sent: 21 November, 2012 13:55
So I'll say it again: if this is always global, there is no reason any
cgroup needs to be involved. If this turns out to be per-process, as
Anton suggested in a recent e-mail, I
Hi,
>
> Memory notifications are quite irrelevant to partitioning and cgroups. The
> use-case is related to user-space handling low memory. Meaning the
> functionality should be accurate with specific granularity (e.g. 1 MB) and
> time (0.25s is OK) but better to have it as simple and
On Tue, Nov 20, 2012 at 10:02:45AM -0800, David Rientjes wrote:
> On Mon, 19 Nov 2012, Glauber Costa wrote:
>
> > >> In the case I outlined below, for backwards compatibility. What I
> > >> actually mean is that memcg *currently* allows arbitrary notifications.
> > >> One way to merge those,
On 11/21/2012 12:46 PM, Anton Vorontsov wrote:
> On Wed, Nov 21, 2012 at 12:27:28PM +0400, Glauber Costa wrote:
>> On 11/20/2012 10:23 PM, David Rientjes wrote:
>>> Anton can correct me if I'm wrong, but I certainly don't think this is
>>> where mempressure is headed: I don't think any accounting
On Wed, Nov 21, 2012 at 12:27:28PM +0400, Glauber Costa wrote:
> On 11/20/2012 10:23 PM, David Rientjes wrote:
> > Anton can correct me if I'm wrong, but I certainly don't think this is
> > where mempressure is headed: I don't think any accounting needs to be done
Yup, I'd rather not do any
On 11/20/2012 10:23 PM, David Rientjes wrote:
> Anton can correct me if I'm wrong, but I certainly don't think this is
> where mempressure is headed: I don't think any accounting needs to be done
> and, if it is, it's a design issue that should be addressed now rather
> than later. I believe
On 11/20/2012 10:23 PM, David Rientjes wrote:
Anton can correct me if I'm wrong, but I certainly don't think this is
where mempressure is headed: I don't think any accounting needs to be done
and, if it is, it's a design issue that should be addressed now rather
than later. I believe
On Wed, Nov 21, 2012 at 12:27:28PM +0400, Glauber Costa wrote:
On 11/20/2012 10:23 PM, David Rientjes wrote:
Anton can correct me if I'm wrong, but I certainly don't think this is
where mempressure is headed: I don't think any accounting needs to be done
Yup, I'd rather not do any
On 11/21/2012 12:46 PM, Anton Vorontsov wrote:
On Wed, Nov 21, 2012 at 12:27:28PM +0400, Glauber Costa wrote:
On 11/20/2012 10:23 PM, David Rientjes wrote:
Anton can correct me if I'm wrong, but I certainly don't think this is
where mempressure is headed: I don't think any accounting needs to
On Tue, Nov 20, 2012 at 10:02:45AM -0800, David Rientjes wrote:
On Mon, 19 Nov 2012, Glauber Costa wrote:
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications.
One way to merge those, while moving to a
Hi,
Memory notifications are quite irrelevant to partitioning and cgroups. The
use-case is related to user-space handling low memory. Meaning the
functionality should be accurate with specific granularity (e.g. 1 MB) and
time (0.25s is OK) but better to have it as simple and
-Original Message-
From: ext Glauber Costa [mailto:glom...@parallels.com]
Sent: 21 November, 2012 13:55
So I'll say it again: if this is always global, there is no reason any
cgroup needs to be involved. If this turns out to be per-process, as
Anton suggested in a recent e-mail, I
-Original Message-
From: ext Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: 21 November, 2012 11:31
...
BTW, there's interface for OOM notification in memcg. See oom_control.
I guess other pressure levels can also fit to the interface.
---
Hi,
I have tracking this conversation
On Mon, 19 Nov 2012, Glauber Costa wrote:
> >> Because cpusets only deal with memory placement, not memory usage.
> >
> > The set of nodes that a thread is allowed to allocate from may face memory
> > pressure up to and including oom while the rest of the system may have a
> > ton of free
On Mon, 19 Nov 2012, Glauber Costa wrote:
> >> In the case I outlined below, for backwards compatibility. What I
> >> actually mean is that memcg *currently* allows arbitrary notifications.
> >> One way to merge those, while moving to a saner 3-point notification, is
> >> to still allow the old
On Mon, 19 Nov 2012, Glauber Costa wrote:
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications.
One way to merge those, while moving to a saner 3-point notification, is
to still allow the old writes and
On Mon, 19 Nov 2012, Glauber Costa wrote:
Because cpusets only deal with memory placement, not memory usage.
The set of nodes that a thread is allowed to allocate from may face memory
pressure up to and including oom while the rest of the system may have a
ton of free memory. Your
>>> Umm, why do users of cpusets not want to be able to trigger memory
>>> pressure notifications?
>>>
>> Because cpusets only deal with memory placement, not memory usage.
>
> The set of nodes that a thread is allowed to allocate from may face memory
> pressure up to and including oom while
On 11/17/2012 05:21 AM, Anton Vorontsov wrote:
> On Fri, Nov 16, 2012 at 01:57:09PM -0800, David Rientjes wrote:
I'm wondering if we should have more than three different levels.
>>>
>>> In the case I outlined below, for backwards compatibility. What I
>>> actually mean is that memcg
On 11/17/2012 01:57 AM, David Rientjes wrote:
> On Sat, 17 Nov 2012, Glauber Costa wrote:
>
>>> I'm wondering if we should have more than three different levels.
>>>
>>
>> In the case I outlined below, for backwards compatibility. What I
>> actually mean is that memcg *currently* allows arbitrary
On 11/17/2012 01:57 AM, David Rientjes wrote:
On Sat, 17 Nov 2012, Glauber Costa wrote:
I'm wondering if we should have more than three different levels.
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary
On 11/17/2012 05:21 AM, Anton Vorontsov wrote:
On Fri, Nov 16, 2012 at 01:57:09PM -0800, David Rientjes wrote:
I'm wondering if we should have more than three different levels.
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows
Umm, why do users of cpusets not want to be able to trigger memory
pressure notifications?
Because cpusets only deal with memory placement, not memory usage.
The set of nodes that a thread is allowed to allocate from may face memory
pressure up to and including oom while the rest of the
On Fri, 16 Nov 2012, Anton Vorontsov wrote:
> The main change is that I decided to go with discrete levels of the
> pressure.
>
> When I started writing the man page, I had to describe the 'reclaimer
> inefficiency index', and while doing this I realized that I'm describing
> how the kernel
On Fri, 16 Nov 2012, Anton Vorontsov wrote:
The main change is that I decided to go with discrete levels of the
pressure.
When I started writing the man page, I had to describe the 'reclaimer
inefficiency index', and while doing this I realized that I'm describing
how the kernel is
On Fri, Nov 16, 2012 at 01:57:09PM -0800, David Rientjes wrote:
> > > I'm wondering if we should have more than three different levels.
> > >
> >
> > In the case I outlined below, for backwards compatibility. What I
> > actually mean is that memcg *currently* allows arbitrary notifications.
> >
On Sat, 17 Nov 2012, Glauber Costa wrote:
> > I'm wondering if we should have more than three different levels.
> >
>
> In the case I outlined below, for backwards compatibility. What I
> actually mean is that memcg *currently* allows arbitrary notifications.
> One way to merge those, while
Hey,
On 11/17/2012 12:04 AM, David Rientjes wrote:
> On Fri, 16 Nov 2012, Glauber Costa wrote:
>
>> My personal take:
>>
>> Most people hate memcg due to the cost it imposes. I've already
>> demonstrated that with some effort, it doesn't necessarily have to be
>> so.
On Fri, 16 Nov 2012, Glauber Costa wrote:
> My personal take:
>
> Most people hate memcg due to the cost it imposes. I've already
> demonstrated that with some effort, it doesn't necessarily have to be
> so. (http://lwn.net/Articles/517634/)
>
> The one thing I missed on that work, was
On 11/16/2012 01:25 AM, David Rientjes wrote:
> On Thu, 15 Nov 2012, Anton Vorontsov wrote:
>
>> Hehe, you're saying that we have to have cgroups=y. :) But some folks were
>> deliberately asking us to make the cgroups optional.
>>
>
> Enabling just CONFIG_CGROUPS (which is enabled by default)
On 11/16/2012 01:25 AM, David Rientjes wrote:
On Thu, 15 Nov 2012, Anton Vorontsov wrote:
Hehe, you're saying that we have to have cgroups=y. :) But some folks were
deliberately asking us to make the cgroups optional.
Enabling just CONFIG_CGROUPS (which is enabled by default) and no other
On Fri, 16 Nov 2012, Glauber Costa wrote:
My personal take:
Most people hate memcg due to the cost it imposes. I've already
demonstrated that with some effort, it doesn't necessarily have to be
so. (http://lwn.net/Articles/517634/)
The one thing I missed on that work, was precisely
Hey,
On 11/17/2012 12:04 AM, David Rientjes wrote:
On Fri, 16 Nov 2012, Glauber Costa wrote:
My personal take:
Most people hate memcg due to the cost it imposes. I've already
demonstrated that with some effort, it doesn't necessarily have to be
so. (http://lwn.net/Articles/517634/)
The
On Sat, 17 Nov 2012, Glauber Costa wrote:
I'm wondering if we should have more than three different levels.
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications.
One way to merge those, while moving to a
On Fri, Nov 16, 2012 at 01:57:09PM -0800, David Rientjes wrote:
I'm wondering if we should have more than three different levels.
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications.
One way to
On Thu, 15 Nov 2012, Anton Vorontsov wrote:
> Hehe, you're saying that we have to have cgroups=y. :) But some folks were
> deliberately asking us to make the cgroups optional.
>
Enabling just CONFIG_CGROUPS (which is enabled by default) and no other
current cgroups increases the size of the
On Thu, Nov 15, 2012 at 12:11:47AM -0800, David Rientjes wrote:
[...]
> Might not be too difficult if you implement your own cgroup to aggregate
> these tasks for which you want to know memory pressure events; it would
> have to be triggered for the task trying to allocate memory at any given
>
On Wed, 14 Nov 2012, Anton Vorontsov wrote:
> Thanks again for your inspirational comments!
>
Heh, not sure I've been too inspirational (probably more annoying than
anything else). I really do want generic memory pressure notifications in
the kernel and already have some ideas on how I can
On Wed, 14 Nov 2012, Anton Vorontsov wrote:
Thanks again for your inspirational comments!
Heh, not sure I've been too inspirational (probably more annoying than
anything else). I really do want generic memory pressure notifications in
the kernel and already have some ideas on how I can tie
On Thu, Nov 15, 2012 at 12:11:47AM -0800, David Rientjes wrote:
[...]
Might not be too difficult if you implement your own cgroup to aggregate
these tasks for which you want to know memory pressure events; it would
have to be triggered for the task trying to allocate memory at any given
On Thu, 15 Nov 2012, Anton Vorontsov wrote:
Hehe, you're saying that we have to have cgroups=y. :) But some folks were
deliberately asking us to make the cgroups optional.
Enabling just CONFIG_CGROUPS (which is enabled by default) and no other
current cgroups increases the size of the
Hi David,
Thanks again for your inspirational comments!
On Wed, Nov 14, 2012 at 07:59:52PM -0800, David Rientjes wrote:
> > > I agree that eventfd is the way to go, but I'll also add that this
> > > feature
> > > seems to be implemented at a far too coarse of level. Memory, and hence
> > >
On Wed, 14 Nov 2012, Anton Vorontsov wrote:
> > I agree that eventfd is the way to go, but I'll also add that this feature
> > seems to be implemented at a far too coarse of level. Memory, and hence
> > memory pressure, is constrained by several factors other than just the
> > amount of
Hi David,
Thanks for your comments!
On Wed, Nov 14, 2012 at 07:21:14PM -0800, David Rientjes wrote:
> > > Why should you be required to use cgroups to get VM pressure events to
> > > userspace?
> >
> > Valid point. But in fact you have it on most systems anyway.
> >
> > I personally don't like
On Wed, 7 Nov 2012, Kirill A. Shutemov wrote:
> > > Sorry, I didn't follow previous discussion on this, but could you
> > > explain what's wrong with memory notifications from memcg?
> > > As I can see you can get pretty similar functionality using memory
> > > thresholds on the root cgroup.
On Wed, 7 Nov 2012, Kirill A. Shutemov wrote:
Sorry, I didn't follow previous discussion on this, but could you
explain what's wrong with memory notifications from memcg?
As I can see you can get pretty similar functionality using memory
thresholds on the root cgroup. What's the
Hi David,
Thanks for your comments!
On Wed, Nov 14, 2012 at 07:21:14PM -0800, David Rientjes wrote:
Why should you be required to use cgroups to get VM pressure events to
userspace?
Valid point. But in fact you have it on most systems anyway.
I personally don't like to have a
On Wed, 14 Nov 2012, Anton Vorontsov wrote:
I agree that eventfd is the way to go, but I'll also add that this feature
seems to be implemented at a far too coarse of level. Memory, and hence
memory pressure, is constrained by several factors other than just the
amount of physical RAM
Hi David,
Thanks again for your inspirational comments!
On Wed, Nov 14, 2012 at 07:59:52PM -0800, David Rientjes wrote:
I agree that eventfd is the way to go, but I'll also add that this
feature
seems to be implemented at a far too coarse of level. Memory, and hence
memory
On Fri, Nov 09, 2012 at 09:32:03AM +0100, Luiz Capitulino wrote:
> Anton Vorontsov wrote:
> > This is the third RFC. As suggested by Minchan Kim, the API is much
> > simplified now (comparing to vmevent_fd):
>
> Which tree is this against? I'd like to try this series, but it doesn't
> apply to
Hi Anton,
On Wed, 7 Nov 2012 02:53:49 -0800
Anton Vorontsov wrote:
> Hi all,
>
> This is the third RFC. As suggested by Minchan Kim, the API is much
> simplified now (comparing to vmevent_fd):
Which tree is this against? I'd like to try this series, but it doesn't
apply to Linus tree.
--
To
Hi Anton,
On Wed, 7 Nov 2012 02:53:49 -0800
Anton Vorontsov anton.voront...@linaro.org wrote:
Hi all,
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
Which tree is this against? I'd like to try this series, but it doesn't
apply
On Fri, Nov 09, 2012 at 09:32:03AM +0100, Luiz Capitulino wrote:
Anton Vorontsov anton.voront...@linaro.org wrote:
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
Which tree is this against? I'd like to try this series, but it
Hi Greg,
On 11/7/12 7:20 PM, Greg Thelen wrote:
> Related question: are there plans to extend this system call to
> provide per-cgroup vm pressure notification?
Yes, that's something that needs to be addressed before we can ever
consider merging something like this to mainline. We probably
On Wed, Nov 07 2012, Kirill A. Shutemov wrote:
> On Wed, Nov 07, 2012 at 02:53:49AM -0800, Anton Vorontsov wrote:
>> Hi all,
>>
>> This is the third RFC. As suggested by Minchan Kim, the API is much
>> simplified now (comparing to vmevent_fd):
>>
>> - As well as Minchan, KOSAKI Motohiro didn't
On Wed, Nov 07, 2012 at 02:11:10PM +0200, Kirill A. Shutemov wrote:
[...]
> >We can have plenty of "free" memory, of which say 90% will be caches,
> >and say 10% idle. But we do want to differentiate these types of memory
> >(although not going into details about it), i.e. we want to
On Wed, Nov 07, 2012 at 01:30:16PM +0200, Pekka Enberg wrote: [...]
> I love the API and implementation simplifications but I hate the new
> ABI. It's a specialized, single-purpose syscall and bunch of procfs
> tunables and I don't see how it's 'extensible' to anything but VM
It is extensible to
On Wed, Nov 07, 2012 at 03:43:46AM -0800, Anton Vorontsov wrote:
> On Wed, Nov 07, 2012 at 01:21:36PM +0200, Kirill A. Shutemov wrote:
> [...]
> > Sorry, I didn't follow previous discussion on this, but could you
> > explain what's wrong with memory notifications from memcg?
> > As I can see you
On Wed, Nov 07, 2012 at 01:21:36PM +0200, Kirill A. Shutemov wrote:
[...]
> Sorry, I didn't follow previous discussion on this, but could you
> explain what's wrong with memory notifications from memcg?
> As I can see you can get pretty similar functionality using memory
> thresholds on the root
On Wed, Nov 07, 2012 at 01:28:12PM +0200, Pekka Enberg wrote:
> On Wed, Nov 7, 2012 at 1:21 PM, Kirill A. Shutemov
> wrote:
> >> While the new API is very simple, it is still extensible (i.e. versioned).
> >
> > Sorry, I didn't follow previous discussion on this, but could you
> > explain what's
On Wed, Nov 7, 2012 at 1:30 PM, Pekka Enberg wrote:
> I love the API and implementation simplifications but I hate the new
> ABI. It's a specialized, single-purpose syscall and bunch of procfs
> tunables and I don't see how it's 'extensible' to anything but VM
s/anything but VM/anything but VM
Hi Anton,
On Wed, Nov 7, 2012 at 12:53 PM, Anton Vorontsov
wrote:
> This is the third RFC. As suggested by Minchan Kim, the API is much
> simplified now (comparing to vmevent_fd):
>
> - As well as Minchan, KOSAKI Motohiro didn't like the timers, so the
> timers are gone now;
> - Pekka Enberg
On Wed, Nov 7, 2012 at 1:21 PM, Kirill A. Shutemov wrote:
>> While the new API is very simple, it is still extensible (i.e. versioned).
>
> Sorry, I didn't follow previous discussion on this, but could you
> explain what's wrong with memory notifications from memcg?
> As I can see you can get
On Wed, Nov 07, 2012 at 02:53:49AM -0800, Anton Vorontsov wrote:
> Hi all,
>
> This is the third RFC. As suggested by Minchan Kim, the API is much
> simplified now (comparing to vmevent_fd):
>
> - As well as Minchan, KOSAKI Motohiro didn't like the timers, so the
> timers are gone now;
> -
Hi all,
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
- As well as Minchan, KOSAKI Motohiro didn't like the timers, so the
timers are gone now;
- Pekka Enberg didn't like the complex attributes matching code, and so it
is no
Hi all,
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
- As well as Minchan, KOSAKI Motohiro didn't like the timers, so the
timers are gone now;
- Pekka Enberg didn't like the complex attributes matching code, and so it
is no
On Wed, Nov 07, 2012 at 02:53:49AM -0800, Anton Vorontsov wrote:
Hi all,
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
- As well as Minchan, KOSAKI Motohiro didn't like the timers, so the
timers are gone now;
- Pekka
On Wed, Nov 7, 2012 at 1:21 PM, Kirill A. Shutemov kir...@shutemov.name wrote:
While the new API is very simple, it is still extensible (i.e. versioned).
Sorry, I didn't follow previous discussion on this, but could you
explain what's wrong with memory notifications from memcg?
As I can see
Hi Anton,
On Wed, Nov 7, 2012 at 12:53 PM, Anton Vorontsov
anton.voront...@linaro.org wrote:
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
- As well as Minchan, KOSAKI Motohiro didn't like the timers, so the
timers are gone
On Wed, Nov 7, 2012 at 1:30 PM, Pekka Enberg penb...@kernel.org wrote:
I love the API and implementation simplifications but I hate the new
ABI. It's a specialized, single-purpose syscall and bunch of procfs
tunables and I don't see how it's 'extensible' to anything but VM
s/anything but
On Wed, Nov 07, 2012 at 01:28:12PM +0200, Pekka Enberg wrote:
On Wed, Nov 7, 2012 at 1:21 PM, Kirill A. Shutemov kir...@shutemov.name
wrote:
While the new API is very simple, it is still extensible (i.e. versioned).
Sorry, I didn't follow previous discussion on this, but could you
On Wed, Nov 07, 2012 at 01:21:36PM +0200, Kirill A. Shutemov wrote:
[...]
Sorry, I didn't follow previous discussion on this, but could you
explain what's wrong with memory notifications from memcg?
As I can see you can get pretty similar functionality using memory
thresholds on the root
On Wed, Nov 07, 2012 at 03:43:46AM -0800, Anton Vorontsov wrote:
On Wed, Nov 07, 2012 at 01:21:36PM +0200, Kirill A. Shutemov wrote:
[...]
Sorry, I didn't follow previous discussion on this, but could you
explain what's wrong with memory notifications from memcg?
As I can see you can get
On Wed, Nov 07, 2012 at 01:30:16PM +0200, Pekka Enberg wrote: [...]
I love the API and implementation simplifications but I hate the new
ABI. It's a specialized, single-purpose syscall and bunch of procfs
tunables and I don't see how it's 'extensible' to anything but VM
It is extensible to VM
On Wed, Nov 07, 2012 at 02:11:10PM +0200, Kirill A. Shutemov wrote:
[...]
We can have plenty of free memory, of which say 90% will be caches,
and say 10% idle. But we do want to differentiate these types of memory
(although not going into details about it), i.e. we want to get
On Wed, Nov 07 2012, Kirill A. Shutemov wrote:
On Wed, Nov 07, 2012 at 02:53:49AM -0800, Anton Vorontsov wrote:
Hi all,
This is the third RFC. As suggested by Minchan Kim, the API is much
simplified now (comparing to vmevent_fd):
- As well as Minchan, KOSAKI Motohiro didn't like the
Hi Greg,
On 11/7/12 7:20 PM, Greg Thelen wrote:
Related question: are there plans to extend this system call to
provide per-cgroup vm pressure notification?
Yes, that's something that needs to be addressed before we can ever
consider merging something like this to mainline. We probably need
80 matches
Mail list logo
