LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "KOSAKI Motohiro" <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kosaki.motohiro@jp.fujitsu.com, marcelo@kvack.org,
daniel.spang@gmail.com, riel@redhat.com,
alan@lxorguk.ukuu.org.uk, linux-fsdevel@vger.kernel.org,
pavel@ucw.cz, a1426z@gawab.com, jonathan@jonmasters.org,
zlynx@acm.org
Subject: Re: [PATCH 4/8][for -mm] mem_notify v6: memory_pressure_notify() caller
Date: Tue, 12 Feb 2008 14:56:51 -0800 [thread overview]
Message-ID: <20080212145651.69cc34a5.akpm@linux-foundation.org> (raw)
In-Reply-To: <2f11576a0802090724s679258c4g7414e0a6983f4706@mail.gmail.com>
On Sun, 10 Feb 2008 00:24:28 +0900
"KOSAKI Motohiro" <kosaki.motohiro@jp.fujitsu.com> wrote:
> the notification point to happen whenever the VM moves an
> anonymous page to the inactive list - this is a pretty good indication
> that there are unused anonymous pages present which will be very likely
> swapped out soon.
>
> and, It is judged out of trouble at the fllowing situations.
> o memory pressure decrease and stop moves an anonymous page to the
> inactive list.
> o free pages increase than (pages_high+lowmem_reserve)*2.
This seems rather arbitrary. Why choose this stage in the page
reclaimation process rather than some other stage?
If this feature is useful then I'd expect that some applications would want
notification at different times, or at different levels of VM distress. So
this semi-randomly-chosen notification point just won't be strong enough in
real-world use.
Does this change work correctly and appropriately for processes which are
running in a cgroup memory controller?
Given the amount of code which these patches add, and the subsequent
maintenance burden, and the unlikelihood of getting many applications to
actually _use_ the interface, it is not obvious to me that inclusion in the
kernel is justifiable, sorry.
memory_pressure_notify() is far too large to be inlined.
Some of the patches were wordwrapped.
next prev parent reply other threads:[~2008-02-12 22:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-09 15:24 KOSAKI Motohiro
2008-02-12 22:56 ` Andrew Morton [this message]
2008-02-13 6:37 ` KOSAKI Motohiro
2008-02-13 15:03 ` Andi Kleen
2008-02-14 0:25 ` KOSAKI Motohiro
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=20080212145651.69cc34a5.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a1426z@gawab.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=daniel.spang@gmail.com \
--cc=jonathan@jonmasters.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo@kvack.org \
--cc=pavel@ucw.cz \
--cc=riel@redhat.com \
--cc=zlynx@acm.org \
--subject='Re: [PATCH 4/8][for -mm] mem_notify v6: memory_pressure_notify() caller' \
/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
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).