Matt,
On Sat, Aug 18, 2007 at 01:40:42AM -0500, Matt Mackall wrote:
> > - On memory pressure,
> > - as VSZ goes up, RSS will be bounded by physical memory.
> > 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.
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 :)
> > > But there are still the downsides I have mentioned:
> > >
> > > - you don't get page frame numbers
> >
> > True. I guess PFNs are meaningless to a normal user?
>
> They're useful for anyone who's trying to look at the system as a
> whole.
>
> > > - you can't do random access
> >
> > Not for now.
> >
> > It would be trivial to support seek-by-address semantic: the seqfile
> > operations already iterate by addresses. Only that we cannot do it via
> > the regular read/pread/seek interfaces. They have different semantic
> > on fpos. However, tricks like ioctl(begin_addr, end_addr) can be
> > employed if necessary.
>
> I suppose. But if you're willing to stomach that sort of thing, you
> might as well use a simple binary interface.
Python can do ioctl() :)
Anyway it's already a special interface.
-
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]
