[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A5BA54C.8070600@embeddedalley.com>
Date: Mon, 13 Jul 2009 14:21:16 -0700
From: "Vladislav D. Buzov" <vbuzov@...eddedalley.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Containers Mailing List
<containers@...ts.linux-foundation.org>,
Dan Malek <dan@...eddedalley.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Menage <menage@...gle.com>,
Balbir Singh <balbir@...ux.vnet.ibm.com>, linux-mm@...ck.org
Subject: Re: [PATCH 1/1] Memory usage limit notification addition to memcg
KAMEZAWA Hiroyuki wrote:
> On Wed, 08 Jul 2009 18:43:48 -0700
> "Vladislav D. Buzov" <vbuzov@...eddedalley.com> wrote:
>
>
>> KAMEZAWA Hiroyuki wrote:
>>
>>> 2 points.
>>> - Do we have to check this always we account ?
>>>
>>>
>> What are the options? Every N pages? How to select N?
>>
>>
> I think you can reuse Balbir's softlimit event counter. (see v9.)
>
It still does not answer the question how to select the number of events
before/between sending the notification.
The idea behind the notification feature is to let user applications
know immediately when a low memory condition occurs (the threshold is
exceeded). So that they can take action to free unused memory before the
OS is involved to handle that (OOM-kill, reclaiming pages).
As far as I understand the reason why you would like to add a delay
between sending notifications is to let user applications some time to
free memory. This is not required by design of the notification feature
because the notification is sent only if someone listening for it.
Typical application will subscribe for low-memory notification, receive
it, handle and then subscribe again. So, even if low memory conditions
keep occurring in mean time, the notification will not be fired. If it
happens again after the user application freed some memory the
application will be immediately notified.
>
>>> If this is true, "set limit" should be checked to guarantee this.
>>> plz allow minus this for avoiding mess.
>>>
>> Setting the memory controller cgroup limit and the notification
>> threshold are two separate operations. There isn't any "mess," just some
>> validation testing for reporting back to the source of the request. When
>> changing the memory controller limit, we ensure the threshold limit is
>> never allowed "negative." At most, the threshold limit will be equal the
>> memory controller cgroup limit. Otherwise, the arithmetic and
>> conditional tests during the operational part of the software becomes
>> more complex, which we don't want.
>>
>>
> Hmm, then, plz this interface put under "set_limit_mutex".
>
I'm going to send another patch soon where I added threshold feature to
the Resource Counter. It's going to address all concerns about data
protection.
Thanks,
Vlad.
> Thanks,
> -Kame
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists