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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 29 Jun 2011 00:56:45 +0200
From:	Andrea Righi <andrea@...terlinux.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Minchan Kim <minchan.kim@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Johannes Weiner <hannes@...xchg.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Jerry James <jamesjer@...terlinux.com>,
	Marcus Sorensen <marcus@...ehost.com>,
	Matt Heaton <matt@...ehost.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, Theodore Tso <tytso@....edu>,
	Shaohua Li <shaohua.li@...el.com>,
	Pádraig Brady <P@...igBrady.com>,
	linux-mm <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/2] fadvise: move active pages to inactive list with
 POSIX_FADV_DONTNEED

On Tue, Jun 28, 2011 at 03:12:33PM -0700, Andrew Morton wrote:
> On Mon, 27 Jun 2011 15:29:19 +0200
> Andrea Righi <andrea@...terlinux.com> wrote:
> 
> > There were some reported problems in the past about trashing page cache when a
> > backup software (i.e., rsync) touches a huge amount of pages (see for example
> > [1]).
> >     
> > This problem has been almost fixed by the Minchan Kim's patch [2] and a proper
> > use of fadvise() in the backup software. For example this patch set [3] has
> > been proposed for inclusion in rsync.
> >     
> > However, there can be still other similar trashing problems: when the backup
> > software reads all the source files, some of them may be part of the actual
> > working set of the system. When a POSIX_FADV_DONTNEED is performed _all_ pages
> > are evicted from pagecache, both the working set and the use-once pages touched
> > only by the backup software.
> >     
> > With the following solution when POSIX_FADV_DONTNEED is called for an active
> > page instead of removing it from the page cache it is added to the tail of the
> > inactive list. Otherwise, if it's already in the inactive list the page is
> > removed from the page cache. Pages mapped by other processes or unevictable
> > pages are not touched at all.
> > 
> > In this way if the backup was the only user of a page, that page will be
> > immediately removed from the page cache by calling POSIX_FADV_DONTNEED.  If the
> > page was also touched by other processes it'll be moved to the inactive list,
> > having another chance of being re-added to the working set, or simply reclaimed
> > when memory is needed.
> 
> So if an application touches a page twice and then runs
> POSIX_FADV_DONTNEED, that page will now not be freed.
> 
> That's a big behaviour change.  For many existing users
> POSIX_FADV_DONTNEED simply doesn't work any more!

Yes. This is the main concern that was raised by Pádraig.

> 
> I'd have thought that adding a new POSIX_FADV_ANDREA would be safer
> than this.

Actually Jerry (in cc) proposed
POSIX_FADV_IDONTNEEDTHISBUTIFSOMEBODYELSEDOESTHENDONTTOUCHIT in a
private email. :)

> 
> 
> The various POSIX_FADV_foo's are so ill-defined that it was a mistake
> to ever use them.  We should have done something overtly linux-specific
> and given userspace more explicit and direct pagecache control.

That would give us the possibility to implement a wide range of
different operations (drop, drop if used once, add to the active list,
add to the inactive list, etc..). Some users always complain that they
would like to have a better control over the page cache from userspace.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ