linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kautuk Consul <consul.kautuk@gmail.com>
To: 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 14:06:28 +0530	[thread overview]
Message-ID: <CAFPAmTQ-7GiDfQkU5wKFfR5UVacrN-HrP5h_yNmAdK8tRO-xTA@mail.gmail.com> (raw)
In-Reply-To: <20120313082818.GA5421@gmail.com>

>
> 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.
> :-)
>

That's true, but we are not talking about higher priority here,
because in extreme memory reclaim case
even PROT_EXEC pages will be reclaimed.

But I understand your point. It might be okay to have this for all
privileges applications.

The only problem that might happen might be in OOM because we will
have to include selection points for
these page-cache pages (proportionately) while finding the most
expensive process to kill.
( I'm talking about the page-cache pages which are not mapped to
usermode page-tables at all. )

If any usermode application reads in an extremely huge file, whose
inode has been set to AS_UNEVICTABLE,
we might want to kill those applications that read in those
pages(proportionately) so that the guilty application
can be killed.

--
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>

  reply	other threads:[~2012-03-13  8:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08  7:34 Zheng Liu
2012-03-08  8:39 ` Greg Thelen
2012-03-08 16:13   ` Zheng Liu
2012-03-08 16:32     ` Zhu Yanhai
2012-03-14  7:19     ` Greg Thelen
2012-03-08  9:35 ` Minchan Kim
2012-03-08 16:54   ` Zheng Liu
2012-03-12  0:28     ` Minchan Kim
2012-03-12  2:06       ` Fwd: " Zheng Liu
2012-03-12  5:19         ` Minchan Kim
2012-03-12  6:20           ` Konstantin Khlebnikov
2012-03-12  8:14             ` Zheng Liu
2012-03-12 13:42               ` Minchan Kim
2012-03-12 14:18                 ` Konstantin Khlebnikov
2012-03-13  2:48                   ` Minchan Kim
2012-03-13  4:37                     ` Konstantin Khlebnikov
2012-03-13  5:00                       ` Konstantin Khlebnikov
2012-03-13  6:30                     ` Zheng Liu
2012-03-13  6:48                       ` Zheng Liu
2012-03-13  7:21                         ` Konstantin Khlebnikov
2012-03-13  7:43                           ` Kautuk Consul
2012-03-13  7:47                             ` Kautuk Consul
2012-03-13  8:05                               ` Zheng Liu
2012-03-13  8:04                                 ` Kautuk Consul
2012-03-13  8:08                                   ` Kautuk Consul
2012-03-13  8:28                                     ` Zheng Liu
2012-03-13  8:36                                       ` Kautuk Consul [this message]
2012-03-13  9:03                                         ` Kautuk Consul
2012-03-12 15:15                 ` Zheng Liu
2012-03-13  2:51                   ` Minchan Kim
2012-03-12 14:55   ` Rik van Riel
2012-03-13  2:57     ` Minchan Kim
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=CAFPAmTQ-7GiDfQkU5wKFfR5UVacrN-HrP5h_yNmAdK8tRO-xTA@mail.gmail.com \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox