Messages in this thread | | | Date | Sat, 3 Feb 2007 00:53:16 -0800 | From | Andrew Morton <> | Subject | Re: [RFC] Tracking mlocked pages and moving them off the LRU |
| |
On Fri, 2 Feb 2007 22:20:12 -0800 (PST) Christoph Lameter <clameter@sgi.com> wrote:
> This is a new variation on the earlier RFC for tracking mlocked pages. > We now mark a mlocked page with a bit in the page flags and remove > them from the LRU. Pages get moved back when no vma that references > the page has VM_LOCKED set anymore. > > This means that vmscan no longer uselessly cycles over large amounts > of mlocked memory should someone attempt to mlock large amounts of > memory (may even result in a livelock on large systems). > > Synchronization is build around state changes of the PageMlocked bit. > The NR_MLOCK counter is incremented and decremented based on > state transitions of PageMlocked. So the count is accurate.
I wonder if it can be simpler. Make two changes:
a) If the scanner encounters an mlocked page on the LRU, take it off.
b) munlock() adds all affected pages to the LRU.
And that's it. Simpler, solves the uselessly-scan-lots-of-mlocked-pages problem (which is the sole requirement according to your description) and doesn't consume a page flag. Optional (and arguable) extension: scan the vmas during munmap, don't add page to LRU if it's still mlocked.
Why _does_ your patch add a new page flag? That info is available via a vma scan.
> There is still some unfinished business: > > 1. We use the 21st page flag and we only have 20 on 32 bit NUMA platforms.
Ow. How were you thinking of fixing that?
> 2. Since mlocked pages are now off the LRU page migration will no longer > move them.
Ow. That could be a right pain when we get around to using migration for memory-unplug?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |