On Sat, 3 Feb 2007, Andrew Morton wrote:
> 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,
Yes, we'd be fine with general reclaim I think. But the calculation of the
dirty ratio based on ZVCs would need it if we take the mlocked pages off.
Otherwise we may have dirty ratios > 100%.
> 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..
Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific
number of mlocked pages. The nice thing about ZVCs is that it allows
easy access to counts on different levels.
> So.. Why do we want NR_MLOCK?
Rik also had some uses in mind for allocation?
-
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]
