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/
