On Sat, Aug 18, 2007 at 12:22:26PM -0500, Matt Mackall wrote: > > > > So VSZ:RSS ratio actually goes up with memory pressure. > > > > > > And yes. > > > > > > But that's not what I'm talking about. You're likely to have more > > > holes in your ranges with memory pressure as things that aren't active > > > get paged or swapped out and back in. And because we're walking the > > > LRU more rapidly, we'll flip over a lot of the active bits more often > > > which will mean more output. > > > > > > > - page range is a good unit of locality. They are more likely to be > > > > reclaimed as a whole. So (RSS:page_ranges) wouldn't degrade as much. > > > > > > There is that. The relative magnitude of the different effects is > > > unclear. But it is clear that the worst case for pmap is much worse > > > > > than pagemap (two lines per page of RSS?). > > It's one line per page. No sane app will make vmas proliferate. > > Sane apps are few and far between.
Very likely, and they will bloat maps/smaps/pmaps alike :( > > So let's talk about the worst case. > > > > pagemap's data set size is determined by VSZ. > > 4GB VSZ means 1M PFNs, hence 8MB pagemap data. > > > > pmaps's data set size is bounded by RSS hence physical memory. > > 4GB RSS means up to 1M page ranges, hence ~20M pmaps data. > > Not too bad :) > > Hmmm, I've been misreading the output. > > What does it do with nonlinear VMAs? The implementation gets offset from page_index(page), so will work the same way in linear/nonlinear VMAs. Depending how one does the remap_file_ranges() calls, the output lines may be not strictly ordered by offset, or overlap, or have small page ranges. - 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/
