From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Kautuk Consul <consul.kautuk@gmail.com>
Cc: minchan@kernel.org, riel@redhat.com,
kosaki.motohiro@jp.fujitsu.com, Zheng Liu <wenqing.lz@taobao.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Fwd: Control page reclaim granularity
Date: Tue, 13 Mar 2012 16:28:18 +0800 [thread overview]
Message-ID: <20120313082818.GA5421@gmail.com> (raw)
In-Reply-To: <CAFPAmTQWsq5sjnTVYL5ark6=LSOmOwiRsCr7wqTp=4ymBAUdUQ@mail.gmail.com>
On Tue, Mar 13, 2012 at 01:38:56PM +0530, Kautuk Consul wrote:
> >
> > I agree, but that's not my point.
> >
> > All I'm saying is that we probably don't want to give normal
> > unprivileged usermode apps
> > the capability to set the mapping to AS_UNEVICTABLE as anyone can then
> > write an application
> > that hogs memory without allowing the kernel to free it through memory reclaim.
Yes, I think so. But it seems that there has some codes that are
possible to be abused. For example, as I said previously, applications
can mmap a normal data file with PROT_EXEC flag. Then this file gets a
high priority to keep in memory (commit: 8cab4754). So my point is that
we cannot control applications how to use these mechanisms. We just
provide them and let applications to choose how to use them.
:-)
Regards,
Zheng
>
> Sorry, I mean :
> "... that hogs kernel unmapped page-cache memory without allowing the
> kernel to free it through memory reclaim."
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Kautuk Consul <consul.kautuk@gmail.com>
Cc: minchan@kernel.org, riel@redhat.com,
kosaki.motohiro@jp.fujitsu.com, Zheng Liu <wenqing.lz@taobao.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: Fwd: Control page reclaim granularity
Date: Tue, 13 Mar 2012 16:28:18 +0800 [thread overview]
Message-ID: <20120313082818.GA5421@gmail.com> (raw)
In-Reply-To: <CAFPAmTQWsq5sjnTVYL5ark6=LSOmOwiRsCr7wqTp=4ymBAUdUQ@mail.gmail.com>
On Tue, Mar 13, 2012 at 01:38:56PM +0530, Kautuk Consul wrote:
> >
> > I agree, but that's not my point.
> >
> > All I'm saying is that we probably don't want to give normal
> > unprivileged usermode apps
> > the capability to set the mapping to AS_UNEVICTABLE as anyone can then
> > write an application
> > that hogs memory without allowing the kernel to free it through memory reclaim.
Yes, I think so. But it seems that there has some codes that are
possible to be abused. For example, as I said previously, applications
can mmap a normal data file with PROT_EXEC flag. Then this file gets a
high priority to keep in memory (commit: 8cab4754). So my point is that
we cannot control applications how to use these mechanisms. We just
provide them and let applications to choose how to use them.
:-)
Regards,
Zheng
>
> Sorry, I mean :
> "... that hogs kernel unmapped page-cache memory without allowing the
> kernel to free it through memory reclaim."
next prev parent reply other threads:[~2012-03-13 8:22 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 7:34 Control page reclaim granularity Zheng Liu
2012-03-08 7:34 ` Zheng Liu
2012-03-08 8:39 ` Greg Thelen
2012-03-08 8:39 ` Greg Thelen
2012-03-08 16:13 ` Zheng Liu
2012-03-08 16:13 ` Zheng Liu
2012-03-08 16:32 ` Zhu Yanhai
2012-03-14 7:19 ` Greg Thelen
2012-03-14 7:19 ` Greg Thelen
2012-03-08 9:35 ` Minchan Kim
2012-03-08 9:35 ` Minchan Kim
2012-03-08 16:54 ` Zheng Liu
2012-03-08 16:54 ` Zheng Liu
2012-03-12 0:28 ` Minchan Kim
2012-03-12 0:28 ` Minchan Kim
2012-03-12 2:06 ` Fwd: " Zheng Liu
2012-03-12 2:06 ` Zheng Liu
2012-03-12 5:19 ` Minchan Kim
2012-03-12 5:19 ` Minchan Kim
2012-03-12 6:20 ` Konstantin Khlebnikov
2012-03-12 6:20 ` Konstantin Khlebnikov
2012-03-12 8:14 ` Zheng Liu
2012-03-12 8:14 ` Zheng Liu
2012-03-12 13:42 ` Minchan Kim
2012-03-12 13:42 ` Minchan Kim
2012-03-12 14:18 ` Konstantin Khlebnikov
2012-03-13 2:48 ` Minchan Kim
2012-03-13 2:48 ` Minchan Kim
2012-03-13 4:37 ` Konstantin Khlebnikov
2012-03-13 4:37 ` Konstantin Khlebnikov
2012-03-13 5:00 ` Konstantin Khlebnikov
2012-03-13 5:00 ` Konstantin Khlebnikov
2012-03-13 6:30 ` Zheng Liu
2012-03-13 6:30 ` Zheng Liu
2012-03-13 6:48 ` Zheng Liu
2012-03-13 6:48 ` Zheng Liu
2012-03-13 7:21 ` Konstantin Khlebnikov
2012-03-13 7:21 ` Konstantin Khlebnikov
2012-03-13 7:43 ` Kautuk Consul
2012-03-13 7:43 ` Kautuk Consul
2012-03-13 7:47 ` Kautuk Consul
2012-03-13 7:47 ` Kautuk Consul
2012-03-13 8:05 ` Zheng Liu
2012-03-13 8:05 ` Zheng Liu
2012-03-13 8:04 ` Kautuk Consul
2012-03-13 8:04 ` Kautuk Consul
2012-03-13 8:08 ` Kautuk Consul
2012-03-13 8:08 ` Kautuk Consul
2012-03-13 8:28 ` Zheng Liu [this message]
2012-03-13 8:28 ` Zheng Liu
2012-03-13 8:36 ` Kautuk Consul
2012-03-13 8:36 ` Kautuk Consul
2012-03-13 9:03 ` Kautuk Consul
2012-03-13 9:03 ` Kautuk Consul
2012-03-12 15:15 ` Zheng Liu
2012-03-12 15:15 ` Zheng Liu
2012-03-13 2:51 ` Minchan Kim
2012-03-13 2:51 ` Minchan Kim
2012-03-12 14:55 ` Rik van Riel
2012-03-12 14:55 ` Rik van Riel
2012-03-13 2:57 ` Minchan Kim
2012-03-13 2:57 ` Minchan Kim
2012-03-13 14:57 ` Rik van Riel
2012-03-13 14:57 ` Rik van Riel
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=20120313082818.GA5421@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=consul.kautuk@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=wenqing.lz@taobao.com \
/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.