linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@parallels.com>
To: Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: David Rientjes <rientjes@google.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Pekka Enberg <penberg@kernel.org>, Mel Gorman <mgorman@suse.de>,
	Leonid Moiseichuk <leonid.moiseichuk@nokia.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Minchan Kim <minchan@kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	John Stultz <john.stultz@linaro.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linaro-kernel@lists.linaro.org, patches@linaro.org,
	kernel-team@android.com, linux-man@vger.kernel.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Michal Hocko <mhocko@suse.cz>,
	Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
Date: Wed, 21 Nov 2012 13:25:52 +0400	[thread overview]
Message-ID: <50AC9E20.2060208@parallels.com> (raw)
In-Reply-To: <20121121084603.GA18159@lizard>

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 be done
> 
> Yup, I'd rather not do any accounting, at least not in bytes.

It doesn't matter here, but memcg doesn't do any accounting in bytes as
well. It only display it in bytes, but internally, it's all pages. The
bytes representation is convenient, because then you can be agnostic of
page sizes.

> 
>>> and, if it is, it's a design issue that should be addressed now rather 
>>> than later.  I believe notifications should occur on current's mempressure 
>>> cgroup depending on its level of reclaim: nobody cares if your memcg has a 
>>> limit of 64GB when you only have 32GB of RAM, we'll want the notification.
>>
>> My main concern is that to trigger those notifications, one would have
>> to first determine whether or not the particular group of tasks is under
>> pressure.
> 
> As far as I understand, the notifications will be triggered by a process
> that tries to allocate memory. So, effectively that would be a per-process
> pressure.
> 
> So, if one process in a group is suffering, we notify that "a process in a
> group is under pressure", and the notification goes to a cgroup listener


If you effectively have a per-process mechanism, why do you need an
extra cgroup at all?

It seems to me that this is simply something that should be inherited
over fork, and then you register the notifier in your first process, and
it will be valid for everybody in the process tree.

If you need tasks in different processes to respond to the same
notifier, then you just register the same notifier in two different
processes.


--
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:[~2012-11-21  9:26 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 10:53 Anton Vorontsov
2012-11-07 11:01 ` [RFC 1/3] mm: Add " Anton Vorontsov
2012-11-08 17:01   ` Mel Gorman
2012-11-08 17:14     ` Kirill A. Shutemov
2012-11-13 18:38   ` Jonathan Corbet
2012-11-07 11:01 ` [RFC 2/3] tools/testing: Add vmpressure-test utility Anton Vorontsov
2012-11-07 11:01 ` [RFC 3/3] man-pages: Add man page for vmpressure_fd(2) Anton Vorontsov
2012-11-07 14:19   ` Rik van Riel
2012-11-20  5:52   ` Andrew Morton
2012-11-20  6:24     ` Anton Vorontsov
2012-11-20 18:12       ` David Rientjes
2012-11-21 15:01         ` Mel Gorman
2012-11-21 19:39           ` Andrew Morton
2012-11-22  8:52             ` Pekka Enberg
2012-11-07 11:21 ` [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications Kirill A. Shutemov
2012-11-07 11:28   ` Pekka Enberg
2012-11-07 11:43     ` Kirill A. Shutemov
2012-11-15  3:21       ` David Rientjes
2012-11-15  3:39         ` Anton Vorontsov
2012-11-15  3:59           ` David Rientjes
2012-11-15  7:34             ` Anton Vorontsov
2012-11-15  8:11               ` David Rientjes
2012-11-15  8:52                 ` Anton Vorontsov
2012-11-15 21:25                   ` David Rientjes
2012-11-16  9:33                     ` Glauber Costa
2012-11-16 20:04                       ` David Rientjes
2012-11-16 21:12                         ` Glauber Costa
2012-11-16 21:57                           ` David Rientjes
2012-11-17  1:21                             ` Anton Vorontsov
2012-11-18 22:53                               ` David Rientjes
2012-11-19 14:00                               ` Glauber Costa
2012-11-19 13:57                             ` Glauber Costa
2012-11-20 18:02                               ` David Rientjes
2012-11-21  9:30                                 ` Kirill A. Shutemov
2012-11-21 11:32                                   ` leonid.moiseichuk
2012-11-21 11:54                                     ` Glauber Costa
2012-11-21 13:48                                       ` leonid.moiseichuk
2012-11-26 21:35                                 ` Michal Hocko
2012-11-19 14:19                             ` Glauber Costa
2012-11-20 18:23                               ` David Rientjes
2012-11-21  8:27                                 ` Glauber Costa
2012-11-21  8:46                                   ` Anton Vorontsov
2012-11-21  9:25                                     ` Glauber Costa [this message]
2012-11-07 11:43   ` Anton Vorontsov
2012-11-07 12:11     ` Kirill A. Shutemov
2012-11-07 12:28       ` Anton Vorontsov
2012-11-07 17:20   ` Greg Thelen
2012-11-07 20:52     ` Pekka Enberg
2012-11-07 11:30 ` Pekka Enberg
2012-11-07 11:31   ` Pekka Enberg
2012-11-07 12:06   ` Anton Vorontsov
2012-11-09  8:32 ` Luiz Capitulino
2012-11-09  9:04   ` Anton Vorontsov

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=50AC9E20.2060208@parallels.com \
    --to=glommer@parallels.com \
    --cc=anton.vorontsov@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=hannes@cmpxchg.org \
    --cc=john.stultz@linaro.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kernel-team@android.com \
    --cc=kirill@shutemov.name \
    --cc=kosaki.motohiro@gmail.com \
    --cc=leonid.moiseichuk@nokia.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=minchan@kernel.org \
    --cc=patches@linaro.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox