John Berthels <[EMAIL PROTECTED]> writes: > I guess I'm saying it may be worth a second look :-)
Well, it locks up my system hard (2.6.12-1.1446_FC5, ie. Fedora rawhide from a while back which might explain it), but if it does what you say it does it would certainly be a very useful tool to have. Since I haven't seen it running, this may be irrelevant, but have you considered the approach of having the kernel module export an interface that would map any given pfn to a list of all its mappings? This would give an overview of how the physical RAM is actually shared by applications, rather than showing how an individual application is using physical RAM. (I think both ways of looking at memory would be useful). For a given vma it might even be possible to tell whether the page had actually been added to the pagetable, or whether it was in the mapping, but not present in the pagetable. (I am possibly revealing my limited understanding of virtual memory here). Having that information would allow us to do things like quantify the cost of having applications still using GtkCList: if only one application used GtkCList, you'd see the physical GtkCList pages mapped into all gtk2 applications, but only present in the pagetable for the CList-using application. Same thing for other rarely-used code, of course. Soeren _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
