linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Pekka Enberg <penberg@kernel.org>,
	Anton Vorontsov <anton.vorontsov@linaro.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
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
Date: Wed, 14 Nov 2012 19:21:14 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1211141910050.14414@chino.kir.corp.google.com> (raw)
In-Reply-To: <20121107114321.GA32265@shutemov.name>

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 point?
> > 
> > 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 syscall per small feature.
> Isn't it better to have a file-based interface which can be used with
> normal file syscalls: open()/read()/poll()?
> 

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 which vmpressure_fd is addressing.  What about 
memory pressure caused by cpusets or mempolicies?  (Memcg has its own 
reclaim logic and its own memory thresholds implemented on top of eventfd 
that people already use.)  These both cause high levels of reclaim within 
the page allocator whereas there may be an abundance of free memory 
available on the system.

I don't think we want several implementations of memory pressure 
notifications, so a more generic and flexible interface is going to be 
needed and I think it can't be done in an extendable way through this 
vmpressure_fd syscall.  Unfortunately, I think that means polling on a 
per-thread notifier.

--
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-15  3:21 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 [this message]
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
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=alpine.DEB.2.00.1211141910050.14414@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=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