linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Anton Vorontsov <anton.vorontsov@linaro.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Mel Gorman <mgorman@suse.de>, Pekka Enberg <penberg@kernel.org>,
	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
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
Date: Wed, 7 Nov 2012 03:43:46 -0800	[thread overview]
Message-ID: <20121107114346.GA32565@lizard> (raw)
In-Reply-To: <20121107112136.GA31715@shutemov.name>

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 cgroup. What's the point?

There are a few reasons we don't use cgroup notifications:

1. We're not interested in the absolute number of pages/KB of available
   memory, as provided by cgroup memory controller. What we're interested
   in is the amount of easily reclaimable memory and new memory
   allocations' cost.

   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
   notified when kernel is reclaiming. And we also want to know when the
   memory comes from swapping others' pages out (well, actually we don't
   call it swap, it's "new allocations cost becomes high" -- it might be a
   result of many factors (swapping, fragmentation, etc.) -- and userland
   might analyze the situation when this happens).

   Exposing all the VM details to userland is not an option -- it is not
   possible to build a stable ABI on this. Plus, it makes it really hard
   for userland to deal with all the low level details of Linux VM
   internals.

   So, no, raw numbers of "free/used KBs" are not interesting at all.

1.5. But it is important to understand that vmpressure_fd() is not
     orthogonal to cgroups (like it was with vmevent_fd()). We want it to
     be "cgroup'able" too. :) But optionally.

2. The last time I checked, cgroups memory controller did not (and I guess
   still does not) not account kernel-owned slabs. I asked several times
   why so, but nobody answered.
   
   But no, this is not the main issue -- per "1.", we're not interested in
   kilobytes.

3. Some folks don't like cgroups: it has a penalty for kernel size, for
   performance and memory wastage. But again, it's not the main issue with
   memcg.

Thanks,
Anton.

--
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-07 11:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 10:53 [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications 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
2012-11-07 11:43   ` Anton Vorontsov [this message]
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=20121107114346.GA32565@lizard \
    --to=anton.vorontsov@linaro.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=john.stultz@linaro.org \
    --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 \
    /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;
as well as URLs for NNTP newsgroup(s).