On Fri, 2 Feb 2007 22:20:12 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
