From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Anton Vorontsov
<anton.vorontsov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"Kirill A. Shutemov"
<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>,
Pekka Enberg <penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mel Gorman <mgorman-l3A5Bk7waGM@public.gmane.org>,
Leonid Moiseichuk
<leonid.moiseichuk-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>,
KOSAKI Motohiro
<kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Bartlomiej Zolnierkiewicz
<b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
kernel-team-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org,
linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications
Date: Mon, 19 Nov 2012 18:19:27 +0400 [thread overview]
Message-ID: <50AA3FEF.2070100@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1211161349420.17853-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
>>> Umm, why do users of cpusets not want to be able to trigger memory
>>> pressure notifications?
>>>
>> Because cpusets only deal with memory placement, not memory usage.
>
> The set of nodes that a thread is allowed to allocate from may face memory
> pressure up to and including oom while the rest of the system may have a
> ton of free memory. Your solution is to compile and mount memcg if you
> want notifications of memory pressure on those nodes. Others in this
> thread have already said they don't want to rely on memcg for any of this
> and, as Anton showed, this can be tied directly into the VM without any
> help from memcg as it sits today. So why implement a simple and clean
> mempressure cgroup that can be used alone or co-existing with either memcg
> or cpusets?
>
Forgot this one:
Because there is a huge ongoing work going on by Tejun aiming at
reducing the effects of orthogonal hierarchy. There are many controllers
today that are "close enough" to each other (cpu, cpuacct; net_prio,
net_cls), and in practice, it brought more problems than it solved.
So yes, *maybe* mempressure is the answer, but it need to be justified
with care. Long term, I think a saner notification API for memcg will
lead us to a better and brighter future.
There is also yet another aspect: This scheme works well for global
notifications. If we would always want this to be global, this would
work neatly. But as already mentioned in this thread, at some point
we'll want this to work for a group of processes as well. At that point,
you'll have to count how much memory is being used, so you can determine
whether or not pressure is going on. You will, then, have to redo all
the work memcg already does.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: David Rientjes <rientjes@google.com>
Cc: 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>,
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: Mon, 19 Nov 2012 18:19:27 +0400 [thread overview]
Message-ID: <50AA3FEF.2070100@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1211161349420.17853@chino.kir.corp.google.com>
>>> Umm, why do users of cpusets not want to be able to trigger memory
>>> pressure notifications?
>>>
>> Because cpusets only deal with memory placement, not memory usage.
>
> The set of nodes that a thread is allowed to allocate from may face memory
> pressure up to and including oom while the rest of the system may have a
> ton of free memory. Your solution is to compile and mount memcg if you
> want notifications of memory pressure on those nodes. Others in this
> thread have already said they don't want to rely on memcg for any of this
> and, as Anton showed, this can be tied directly into the VM without any
> help from memcg as it sits today. So why implement a simple and clean
> mempressure cgroup that can be used alone or co-existing with either memcg
> or cpusets?
>
Forgot this one:
Because there is a huge ongoing work going on by Tejun aiming at
reducing the effects of orthogonal hierarchy. There are many controllers
today that are "close enough" to each other (cpu, cpuacct; net_prio,
net_cls), and in practice, it brought more problems than it solved.
So yes, *maybe* mempressure is the answer, but it need to be justified
with care. Long term, I think a saner notification API for memcg will
lead us to a better and brighter future.
There is also yet another aspect: This scheme works well for global
notifications. If we would always want this to be global, this would
work neatly. But as already mentioned in this thread, at some point
we'll want this to work for a group of processes as well. At that point,
you'll have to count how much memory is being used, so you can determine
whether or not pressure is going on. You will, then, have to redo all
the work memcg already does.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: David Rientjes <rientjes@google.com>
Cc: 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>,
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: Mon, 19 Nov 2012 18:19:27 +0400 [thread overview]
Message-ID: <50AA3FEF.2070100@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1211161349420.17853@chino.kir.corp.google.com>
>>> Umm, why do users of cpusets not want to be able to trigger memory
>>> pressure notifications?
>>>
>> Because cpusets only deal with memory placement, not memory usage.
>
> The set of nodes that a thread is allowed to allocate from may face memory
> pressure up to and including oom while the rest of the system may have a
> ton of free memory. Your solution is to compile and mount memcg if you
> want notifications of memory pressure on those nodes. Others in this
> thread have already said they don't want to rely on memcg for any of this
> and, as Anton showed, this can be tied directly into the VM without any
> help from memcg as it sits today. So why implement a simple and clean
> mempressure cgroup that can be used alone or co-existing with either memcg
> or cpusets?
>
Forgot this one:
Because there is a huge ongoing work going on by Tejun aiming at
reducing the effects of orthogonal hierarchy. There are many controllers
today that are "close enough" to each other (cpu, cpuacct; net_prio,
net_cls), and in practice, it brought more problems than it solved.
So yes, *maybe* mempressure is the answer, but it need to be justified
with care. Long term, I think a saner notification API for memcg will
lead us to a better and brighter future.
There is also yet another aspect: This scheme works well for global
notifications. If we would always want this to be global, this would
work neatly. But as already mentioned in this thread, at some point
we'll want this to work for a group of processes as well. At that point,
you'll have to count how much memory is being used, so you can determine
whether or not pressure is going on. You will, then, have to redo all
the work memcg already does.
next prev parent reply other threads:[~2012-11-19 14:19 UTC|newest]
Thread overview: 134+ 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 10:53 ` Anton Vorontsov
2012-11-07 10:53 ` Anton Vorontsov
2012-11-07 11:01 ` [RFC 1/3] mm: Add " Anton Vorontsov
2012-11-07 11:01 ` Anton Vorontsov
2012-11-08 17:01 ` Mel Gorman
2012-11-08 17:01 ` Mel Gorman
2012-11-08 17:01 ` Mel Gorman
[not found] ` <20121108170124.GB8218-l3A5Bk7waGM@public.gmane.org>
2012-11-08 17:14 ` Kirill A. Shutemov
2012-11-08 17:14 ` Kirill A. Shutemov
2012-11-08 17:14 ` Kirill A. Shutemov
2012-11-13 18:38 ` Jonathan Corbet
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 ` Anton Vorontsov
2012-11-07 11:01 ` [RFC 3/3] man-pages: Add man page for vmpressure_fd(2) Anton Vorontsov
2012-11-07 11:01 ` Anton Vorontsov
2012-11-07 11:01 ` Anton Vorontsov
2012-11-07 14:19 ` Rik van Riel
2012-11-07 14:19 ` Rik van Riel
2012-11-20 5:52 ` Andrew Morton
2012-11-20 5:52 ` Andrew Morton
2012-11-20 5:52 ` Andrew Morton
[not found] ` <20121119215211.6370ac3b.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-11-20 6:24 ` Anton Vorontsov
2012-11-20 6:24 ` Anton Vorontsov
2012-11-20 6:24 ` Anton Vorontsov
2012-11-20 18:12 ` David Rientjes
2012-11-20 18:12 ` David Rientjes
2012-11-20 18:12 ` David Rientjes
[not found] ` <alpine.DEB.2.00.1211201004390.4200-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-21 15:01 ` Mel Gorman
2012-11-21 15:01 ` Mel Gorman
2012-11-21 15:01 ` Mel Gorman
2012-11-21 19:39 ` Andrew Morton
2012-11-21 19:39 ` Andrew Morton
2012-11-22 8:52 ` Pekka Enberg
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:21 ` Kirill A. Shutemov
2012-11-07 11:43 ` Anton Vorontsov
2012-11-07 11:43 ` Anton Vorontsov
2012-11-07 12:11 ` Kirill A. Shutemov
2012-11-07 12:11 ` Kirill A. Shutemov
[not found] ` <20121107121110.GA32402-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-11-07 12:28 ` Anton Vorontsov
2012-11-07 12:28 ` Anton Vorontsov
2012-11-07 12:28 ` Anton Vorontsov
[not found] ` <20121107112136.GA31715-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-11-07 11:28 ` Pekka Enberg
2012-11-07 11:28 ` Pekka Enberg
2012-11-07 11:28 ` Pekka Enberg
[not found] ` <CAOJsxLHY+3ZzGuGX=4o1pLfhRqjkKaEMyhX0ejB5nVrDvOWXNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-07 11:43 ` Kirill A. Shutemov
2012-11-07 11:43 ` Kirill A. Shutemov
2012-11-07 11:43 ` Kirill A. Shutemov
[not found] ` <20121107114321.GA32265-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-11-15 3:21 ` David Rientjes
2012-11-15 3:21 ` David Rientjes
2012-11-15 3:21 ` David Rientjes
[not found] ` <alpine.DEB.2.00.1211141910050.14414-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-15 3:39 ` Anton Vorontsov
2012-11-15 3:39 ` Anton Vorontsov
2012-11-15 3:39 ` Anton Vorontsov
2012-11-15 3:59 ` David Rientjes
2012-11-15 3:59 ` David Rientjes
[not found] ` <alpine.DEB.2.00.1211141946370.14414-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-15 7:34 ` Anton Vorontsov
2012-11-15 7:34 ` Anton Vorontsov
2012-11-15 7:34 ` Anton Vorontsov
[not found] ` <20121115073420.GA19036-SAfYLu58TvsAzdhXFe8piDcLetGT9WKNKwcig+XE9tjR7s880joybQ@public.gmane.org>
2012-11-15 8:11 ` David Rientjes
2012-11-15 8:11 ` David Rientjes
2012-11-15 8:11 ` David Rientjes
2012-11-15 8:52 ` Anton Vorontsov
2012-11-15 8:52 ` Anton Vorontsov
2012-11-15 21:25 ` David Rientjes
2012-11-15 21:25 ` David Rientjes
[not found] ` <alpine.DEB.2.00.1211151303510.27188-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-16 9:33 ` Glauber Costa
2012-11-16 9:33 ` Glauber Costa
2012-11-16 9:33 ` Glauber Costa
[not found] ` <50A60873.3000607-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-11-16 20:04 ` David Rientjes
2012-11-16 20:04 ` David Rientjes
2012-11-16 20:04 ` David Rientjes
2012-11-16 21:12 ` Glauber Costa
2012-11-16 21:12 ` Glauber Costa
2012-11-16 21:57 ` David Rientjes
2012-11-16 21:57 ` David Rientjes
2012-11-17 1:21 ` Anton Vorontsov
2012-11-17 1:21 ` Anton Vorontsov
2012-11-18 22:53 ` David Rientjes
2012-11-18 22:53 ` David Rientjes
[not found] ` <20121117012114.GA22910-SAfYLu58TvubUOgZnPAKMoC2/QZ1MJnMKwcig+XE9tjR7s880joybQ@public.gmane.org>
2012-11-19 14:00 ` Glauber Costa
2012-11-19 14:00 ` Glauber Costa
2012-11-19 14:00 ` Glauber Costa
[not found] ` <alpine.DEB.2.00.1211161349420.17853-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-19 13:57 ` Glauber Costa
2012-11-19 13:57 ` Glauber Costa
2012-11-19 13:57 ` Glauber Costa
2012-11-20 18:02 ` David Rientjes
2012-11-20 18:02 ` David Rientjes
[not found] ` <alpine.DEB.2.00.1211200950120.4200-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-21 9:30 ` Kirill A. Shutemov
2012-11-21 9:30 ` Kirill A. Shutemov
2012-11-21 9:30 ` Kirill A. Shutemov
2012-11-21 11:32 ` leonid.moiseichuk
2012-11-21 11:32 ` leonid.moiseichuk
2012-11-21 11:54 ` Glauber Costa
2012-11-21 11:54 ` Glauber Costa
2012-11-21 13:48 ` leonid.moiseichuk
2012-11-21 13:48 ` leonid.moiseichuk
2012-11-26 21:35 ` Michal Hocko
2012-11-26 21:35 ` Michal Hocko
2012-11-19 14:19 ` Glauber Costa [this message]
2012-11-19 14:19 ` Glauber Costa
2012-11-19 14:19 ` Glauber Costa
[not found] ` <50AA3FEF.2070100-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-11-20 18:23 ` David Rientjes
2012-11-20 18:23 ` David Rientjes
2012-11-20 18:23 ` David Rientjes
[not found] ` <alpine.DEB.2.00.1211201013460.4200-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
2012-11-21 8:27 ` Glauber Costa
2012-11-21 8:27 ` Glauber Costa
2012-11-21 8:27 ` Glauber Costa
2012-11-21 8:46 ` Anton Vorontsov
2012-11-21 8:46 ` Anton Vorontsov
2012-11-21 9:25 ` Glauber Costa
2012-11-21 9:25 ` Glauber Costa
2012-11-07 17:20 ` Greg Thelen
2012-11-07 17:20 ` Greg Thelen
2012-11-07 17:20 ` Greg Thelen
[not found] ` <xr93liedfhy4.fsf-aSPv4SP+Du0KgorLzL7FmE7CuiCeIGUxQQ4Iyu8u01E@public.gmane.org>
2012-11-07 20:52 ` Pekka Enberg
2012-11-07 20:52 ` Pekka Enberg
2012-11-07 20:52 ` Pekka Enberg
2012-11-07 11:30 ` Pekka Enberg
2012-11-07 11:30 ` Pekka Enberg
2012-11-07 11:30 ` Pekka Enberg
[not found] ` <CAOJsxLFz+Zi=A0uyuNMj411ngjwpstakNY3fEWy6tW_h4whr7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-07 11:31 ` Pekka Enberg
2012-11-07 11:31 ` Pekka Enberg
2012-11-07 11:31 ` Pekka Enberg
2012-11-07 12:06 ` Anton Vorontsov
2012-11-07 12:06 ` Anton Vorontsov
2012-11-07 12:06 ` Anton Vorontsov
2012-11-09 8:32 ` Luiz Capitulino
2012-11-09 8:32 ` Luiz Capitulino
2012-11-09 9:04 ` Anton Vorontsov
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=50AA3FEF.2070100@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=anton.vorontsov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=kernel-team-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org \
--cc=kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org \
--cc=kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=leonid.moiseichuk-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org \
--cc=linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mgorman-l3A5Bk7waGM@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=penberg-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.