Messages in this thread | | | Subject | Re: [patch 17/20] non-reclaimable mlocked pages | From | Peter Zijlstra <> | Date | Wed, 19 Dec 2007 15:24:07 +0100 |
| |
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@yahoo.com.au> wrote: > > > On Wednesday 19 December 2007 08:15, Rik van Riel wrote: > > > > > Rework of a patch by Nick Piggin -- part 1 of 2. > > > > > > This patch: > > > > > > 1) defines the [CONFIG_]NORECLAIM_MLOCK sub-option and the > > > stub version of the mlock/noreclaim APIs when it's > > > not configured. Depends on [CONFIG_]NORECLAIM. > > > 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? > > > These mlocked pages don't need to be on a non-reclaimable list, > > because we can find them again via the ptes when they become > > unlocked, and there is no point background scanning them, because > > they're always going to be locked while they're mlocked.
I thought Lee had patches that moved pages with long rmap chains (both anon and file) out onto the non-reclaim list, for those a slow background scan does make sense.
| |