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:	Thu, 20 Dec 2007 15:56:27 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 17/20] non-reclaimable mlocked pages

On Wed, 19 Dec 2007 11:04:26 -0500
Lee Schermerhorn <Lee.Schermerhorn@...com> wrote:
> On Wed, 2007-12-19 at 08:45 -0500, Rik van Riel wrote:
> > On Wed, 19 Dec 2007 11:56:48 +1100
> > Nick Piggin <nickpiggin@...oo.com.au> wrote:

> > > Hmm, I still don't know (or forgot) why you don't just use the
> > > old scheme of having an mlock count in the LRU bit, and removing
> > > the mlocked page from the LRU completely.
> > 
> > How do we detect those pages reliably in the lumpy reclaim code?
> 
> I wanted to try to treat nonreclaimable pages, whatever the reason,
> uniformly.  Lumpy reclaim wasn't there when I started on this, but we've
> been able to handle them.  I was more interested in page migration.  The
> act of isolating the page from the LRU [under zone lru_lock] arbitrates
> between racing tasks attempting to migrate the same page.  That and we
> keep the isolated pages on a list using the LRU links.  We can't migrate
> pages that we can't successfully isolate from the LRU list.

Good point.

Lets keep the nonreclaimable pages on a list, so we can keep
the migration code (and other code) consistent.

We can deal with lazily moving pages back to the nonreclaim
list if we find that, after one munlock, there are other
mlocking users of that page.

> I also agree they don't need to be scanned.  And, altho' having them on
> an LRU list has other uses, I suppose that having mlocked pages on the
> noreclaim list could be considered "clutter" if we did want to scan the
> noreclaim list for other types of non-reclaimable pages that might have
> become reclaimable.  

If we ever want to do that, we can always introduce separate
lists for those pages.
--
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