linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: David Rientjes <rientjes@google.com>
Cc: Glauber Costa <glommer@parallels.com>,
	Anton Vorontsov <anton.vorontsov@linaro.org>,
	"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>,
	Johannes Weiner <hannes@cmpxchg.org>, Tejun Heo <tj@kernel.org>
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
Date: Mon, 26 Nov 2012 22:35:16 +0100	[thread overview]
Message-ID: <20121126213516.GD12602@dhcp22.suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.00.1211200950120.4200@chino.kir.corp.google.com>

[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, while moving to a saner 3-point notification, is
> > >> to still allow the old writes and fit them in the closest bucket.
> > >>
> > > 
> > > Yeah, but I'm wondering why three is the right answer.
> > > 
> > 
> > This is unrelated to what I am talking about.
> > I am talking about pre-defined values with a specific event meaning (in
> > his patchset, 3) vs arbitrary numbers valued in bytes.
> > 
> 
> Right, and I don't see how you can map the memcg thresholds onto Anton's 
> scheme that heavily relies upon reclaim activity; what bucket does a 
> threshold of 48MB in a memcg with a limit of 64MB fit into?
> Perhaps you have some formula in mind that would do this, but I don't
> see how it works correctly without factoring in configuration options
> (memory compaction), type of allocation (GFP_ATOMIC won't trigger
> Anton's reclaim scheme like GFP_KERNEL), altered min_free_kbytes, etc.
> 
> This begs the question of whether the new cgroup should be considered as a 
> replacement for memory thresholds within memcg in the first place; 
> certainly both can coexist just fine.

Absolutely agreed. Yes those two things are inherently different.
Information that "you have passed half of your limit" is something
totally different than "you should slow down". Although I am not
entirely sure what the first is one good for (to be honest), but I
believe there are users out there.

I do not think that mixing those two makes much sense. They have
different usecases and until we have users for the thresholds one we
should keep it.

[...]

Thanks
-- 
Michal Hocko
SUSE Labs

--
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>

  parent reply	other threads:[~2012-11-26 21:35 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 [this message]
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
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=20121126213516.GD12602@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=anton.vorontsov@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=glommer@parallels.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=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