[Crash-utility] [PATCH] display MCNT and PRIVATE when using kmem -p

[qiaonuohan]

Hello Dave,

I think it is necessary to see what is hided in the union where 
_mapcount lies. However, as you said, it's hard to pick which fields are 
more important than others when adding new items to "kmem -p". So I 
think over using struct sub-command to show what I want.

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)
3. it can output easy-parsing format (using an option to specify), maybe 
like 'kmem -p'. For example,
crash> struct page.flags,_count.counter -.. < PAGE_list.txt
    1024    0
    1024    1
    1024    1
    1024    1

After adding these features to struct sub-command, I guess it is more 
easier to get information hiding in structs and parsing it. Before 
implementing, I feel the necessity to ask you for some advices. So what 
about these features?

At 2012-1-6 3:37, Dave Anderson wrote:
> 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?


-- 
--
Regards
Qiao Nuohan