On Sat, 3 Feb 2007 11:03:59 -0800 (PST) Christoph Lameter <[email protected]> wrote:
> Here is the second piece removing mlock pages off the LRU during scanning.
> I tried moving them to a separate list but then we run into issues with
> locking. We do not need ithe list though since we will encounter the
> page again anyways during zap_pte_range.
>
> However, in zap_pte_range we then run into another problem. Multiple
> zap_pte_ranges may handle the same page and without a page flag and
> scanning all the vmas we cannot determine if the page should or should not
> be moved back to the LRU. As a result this patch may decrement NR_MLOCK
> too much so that is goes below zero. Any ideas on how to fix this without
> a page flag and a scan over vmas?
>
> Plus there is the issue of NR_MLOCK only being updated when we are
> reclaiming and when we may already be in trouble. An app may mlock huge
> amounts of memory and NR_MLOCK will stay low. If memory gets too low then
> NR_MLOCKED is suddenly become accurate and the VM is likely undergoing a
> shock from that discovery (should we actually use NR_MLOCK elsewhere to
> determine memory management behavior). Hopefully we will not fall over
> then.
Do we actually need NR_MLOCK? Page reclaim tends to care more about the
size of the LRUs and doesn't have much dependency on ->present_pages,
iirc.
I guess we could use NR_MLOCK for writeback threshold calculations, to
force writeback earlier if there's a lot of mlocked memory in the affected
zones. But that code isn't zone-aware anyway, and we don't know how to make
it zone aware in any sane fashion and making it cpuset-aware isn't very
interesting or useful..
So.. Why do we want NR_MLOCK?
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
