VM accounting

[Alessandro.Forin@SPICE.CS.CMU.EDU]

Guys,
I wrote a little program to convince me I knew what is going on.
You can find it in /../countach/usr/af/bugs/kmap, and it can be
run (as root) on all mipsmach boxes.
It is a very useful and very ashameful coded toy (aren't all useful 
things ashameful ?) that prints out this sort of things [this was
taken while lisp was running]

	testarossa:af trash> kmap -v
	Physical page list accounts for 3533 pages:
	3311 pages in the list are busy and 222 free
	Busy pages: (approx) 2699 user and 612 kernel
	Kernel fixed size (image+bss+symtab+U*xtables): circa 562 pages
	Pages accounted for: 4095 out of 4095.
	
	Virtual page accounting:
	Free:        68 pages
	Inactive:    67 pages
	User:      2703 pages
	Kernel:    1438 pages
	Pages accounted for: between 4209 and 4276 out of 4095

This program looks at memory utilization from two angles: it makes an
account of all physical pages, and it looks at the pagetables for all
virtual mappings. Due to sharing and the sophisticated paging strategy
the virtual account is bound to be wrong, the program only prints it
with the "-v" switch.   There is also a -l switch that gives you a
humungous printout that accounts for each and every single page.

The bottom line is that on my machine, with the simple patch that
I mentioned in the previous message to limit the buffer cache I see
now that the memory usage floats between
	idle mode:
		Kernel		1183 pages (4.7 meg)
		User-or-free	2912 pages (11.6 meg)
	extreme load:
		kernel		1167 pages (4.6 meg)
		User		2928 pages (11.7 meg)

["Kernel" is kernel busy + kernel fixed, "user" is user busy + free]
As you can see the kernel is pretty stubborn about his pages (this
can be improved, but not dramatically) but it is also quite consistent.

Questions&comments ?

sandro-
PS: the time to compile seq.lisp on my machine is down to 23 minutes,
was 31 before.