[Crash-utility] Issues with kmem -i
Dave Anderson
anderson at redhat.com
Mon Apr 10 15:26:14 UTC 2006
Sharyathi Nagesh wrote:
> On executing kmem -i over dump we are seeing these results
>
> crash> kmem -i
> PAGES TOTAL PERCENTAGE
> TOTAL MEM 128778 503 MB ----
> FREE 44244 172.8 MB 34% of TOTAL MEM
> USED 84534 330.2 MB 65% of TOTAL MEM
> SHARED 45690 178.5 MB 35% of TOTAL MEM
> BUFFERS 4371 17.1 MB 3% of TOTAL MEM
> CACHED 51358 200.6 MB 39% of TOTAL MEM
> SLAB 0 0 0% of TOTAL MEM
>
> TOTAL HIGH 0 0 0% of TOTAL MEM
>
> This is due to the fact that
> o mi->get_slabs field is turning out to be zero in dump_mem_map()
> function. This is happening as vt->PG_slab field is not getting updated
> with value(10 in this case) in vm_init(). This is happening as pte field
> is taken from page structure.
> o Probable solutions: Hard code value vt->PG_slab ??
That makes the most sense at this point. This is what I was
planning for vm_init():
@@ -694,7 +708,8 @@ vm_init(void)
vt->PG_slab = 10;
else if (THIS_KERNEL_VERSION >= LINUX(2,6,0))
vt->PG_slab = 7;
- }
+ } else if (THIS_KERNEL_VERSION >= LINUX(2,6,0))
+ vt->PG_slab = 7;
}
/*
>
>
> o The output is breaking as totalhigh_pages is coming out zero,
> So part of code in function dump_kmeminfo()
> pct = freehighmem_pages ?
> (freehighmem_pages * 100)/totalhigh_pages : 0;
> Cause Arithmetic calculation error.
>
> Still looking into the problem.
I can't reproduce this one. In your case though, with
about 500MB, both "freehighmem_pages" and "totalhigh_pages"
should both be zero, leading to a "pct" setting of 0.
Are you showing "freehighmem_pages" as non-zero?
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060410/8ce769be/attachment.htm>
More information about the Crash-utility
mailing list