[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFPAmTQ-7GiDfQkU5wKFfR5UVacrN-HrP5h_yNmAdK8tRO-xTA@mail.gmail.com>
Date: Tue, 13 Mar 2012 14:06:28 +0530
From: Kautuk Consul <consul.kautuk@...il.com>
To: minchan@...nel.org, riel@...hat.com,
kosaki.motohiro@...fujitsu.com, Zheng Liu <wenqing.lz@...bao.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: Fwd: Control page reclaim granularity
>
> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists