linux-kernel - Re: Fwd: Control page reclaim granularity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Mar 2012 13:17:41 +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
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Fwd: Control page reclaim granularity

On Tue, Mar 13, 2012 at 1:13 PM, Kautuk Consul <consul.kautuk@...il.com> wrote:
> Hi,
>
> I noticed this discussion and decided to pitch in one small idea from my side.
>
> It would be nice to range lock an inode's pages by storing those
> ranges which would be locked.
> This could also add some good routines for the kernel in terms of
> range locking for a single inode.
> However, wouldn't this add some overhead to shrink_page_list() since
> that code would need to go through
> all these ranges while trying to reclaim a single page ?
>
> One small suggestion from my side is:
> Why don't we implement something like : "Complete page-cache reclaim
> control from usermode"?
> In this, we can set/unset the mapping to AS_UNEVICTABLE (as Konstantin
> mentioned) for a file's
> inode from usermode by using ioctl or fcntl or maybe even go as far as
> implementing an O_NORECL
> option to the open system call.
>

Of course, only an application executing with root privileges should
be allowed to set the inode's
mapping flags in this manner.


> After setting the AS_UNEVICTABLE, the usermode application can choose
> to keep and remove pages by
> using the fadvise(WILLNEED) and fadvise(DONTNEED).
>
> ( I think maybe the presence of any VMA is might not really be
> required for this idea. )
>
> Thanks,
> Kautuk.
--
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/