Re: [Crash-utility] [PATCH] display MCNT and PRIVATE when using kmem -p
----- Original Message -----
Hello Dave,
I was using ‘kmem –p’ to get status of memory. And I could only get
"PAGE PHYSICAL MAPPING INDEX CNT FLAGS" in 2.6.x kernel and later, which
makes me feel the lack of information. So I think of displaying
‘page._mapcount’ and ‘page.private’, when using ‘kmem -p’.
When adding these two items, I found ‘page._count’ is declared to be
atomic_t whose definition is:
typedef struct {
volatile int counter;
} atomic_t;
However, current crash codes use UINT to get the value of ‘page._count’.
But it doesn't make any difference, right? The value is fprintf'd
with %d, so it is converted to a signed value.
The first patch (0001-kmem_p_6.0.2.patch) is used to change UINT to INT,
and the second one (0002-kmem_p_6.0.2.patch) will add the items talked
above. Both patches are based on crash 6.0.2.
BTW, I have tested these two patches on RHEL6.2_x86_64, RHEL6.2_i386,
RHEL5.8_x86_64 and RHEL5.8_i386.
I appreciate the effort, but I'm not sure whether it's worth changing
it at this point, or whether it could be accomplished in a different
manner.
The primary purpose for "kmem -p" is to show the page structure
address associated with each physical address in the system -- along
with "basic information about each page". It's had those basic
fields in it forever -- which BTW, fit into 80 columns. I prefer not
to have command output exceed 80 columns unless it is impossible to
predict the size of an output field.
Anyway, the page structure definition keeps changing over time, more
specifically the embedded anonymous structures contained within it, and
the fields within the anonymous structs have multiple meanings. With
your patch, the output becomes cluttered and hard to understand, especially
due to the strange values that can be seen in the MCNT column when it's
not a counter value, but rather a slab-page construct:
union {
atomic_t _mapcount;
struct {
unsigned inuse:16;
unsigned objects:15;
unsigned frozen:1;
};
};
And so it's hard to pick which fields are more important than others,
because it pretty much depends upon what's being debugged. You have
picked the private field (which can have numerous meanings), but for
example, there have been times in the past where I wanted to see the
lru list_head contents.
That all being said, your patch does have merit, but I wonder if there
could be an alternate way of selecting or filtering what fields are
displayed?
Dave