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’.
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.
--
Regards
Qiao Nuohan
diff --git a/defs.h b/defs.h
index 82d51e5..bcf8d6b 100755
--- a/defs.h
+++ b/defs.h
@@ -1184,6 +1184,8 @@ struct offset_table { /* stash of commonly-used offsets */
long page_buffers;
long page_lru;
long page_pte;
+ long page_mapcount;
+ long page_private;
long swap_info_struct_swap_file;
long swap_info_struct_swap_vfsmnt;
long swap_info_struct_flags;
diff --git a/memory.c b/memory.c
index 9e8e7d0..15e2b0f 100755
--- a/memory.c
+++ b/memory.c
@@ -374,6 +374,12 @@ vm_init(void)
MEMBER_OFFSET_INIT(page_buffers, "page", "buffers");
MEMBER_OFFSET_INIT(page_lru, "page", "lru");
MEMBER_OFFSET_INIT(page_pte, "page", "pte");
+ MEMBER_OFFSET_INIT(page_mapcount, "page", "_mapcount");
+ if (INVALID_MEMBER(page_mapcount))
+ ANON_MEMBER_OFFSET_INIT(page_mapcount, "page", "_mapcount");
+ MEMBER_OFFSET_INIT(page_private, "page", "private");
+ if (INVALID_MEMBER(page_private))
+ ANON_MEMBER_OFFSET_INIT(page_private, "page", "private");
switch (mi->flags)
{
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
02-28-2012, 04:54 AM
qiaonuohan
display MCNT and PRIVATE when using kmem -p
At 2012-1-10 21:54, Dave Anderson wrote:
----- Original Message -----
Hello Dave,
Glad to hear the capability is desirable. I will start to implement this
soon.
What if I change struct sub-command to this:
1. it can refer to anonymous members (e.g., page._mapcount)
2. it can refer to submembers(e.g., page._count.counter)
One other suggestion -- I believe it should not be necessary to
support the "page._count.counter" format, because you can get
the data by using the container name. Taking the "_count.counter"
example:
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Hello Dave,
Sorry for reacting late. I have started to realize these item we talked
before. But, considering your mail about "page._count.counter" format, I
need to explain my opinion to you. Trying to support the
"page._count.counter" format is used to help implementing the formatted
output like:
Compared with "p ((struct page *)0xffffea0000000200)._count.counter",
which can only display only one data each time, the former style can be
more helpful when parsing the output.
The reason why I want the "page._count.counter" format is I want to
offer an efficient way to collect a lot of data. Then I'd like you to
give some comments. Thanks.
--
--
Regards
Qiao Nuohan
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility