linux-kernel - Re: [patch 17/20] non-reclaimable mlocked pages

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]

Message-Id: <200712212152.19260.nickpiggin@yahoo.com.au>
Date:	Fri, 21 Dec 2007 21:52:19 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Rik van Riel <riel@...hat.com>
Cc:	Lee Schermerhorn <Lee.Schermerhorn@...com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 17/20] non-reclaimable mlocked pages

On Friday 21 December 2007 07:56, Rik van Riel wrote:
> 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.

Ah: that's what it was. The migration code got harder with my mlock
code (although I did have something that should have worked in theory,
it involved a few steps).

I don't have a particular problem with putting mlock pages on the slow
scan lists, although if you have huge mlocked data sets, you could
effectively speed up slow scan list scanning by orders of magnitude by
avoiding the mlocked pages.

I won't push it now, but I might see if I can rewrite it one day :)

BTW. if you have any workloads that are limited by page reclaim,
especially unmapped file backed pagecache reclaim, then I have some
stright-line-speedup patches which you might find interesting (I can
send them if you'd like to test).
--
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/