[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Kernel 1183 pages (4.7 meg)
User-or-free 2912 pages (11.6 meg)
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.
PS: the time to compile seq.lisp on my machine is down to 23 minutes,
was 31 before.