List Info

Thread: Need to update page->flags




Need to update page->flags
user name
2006-03-21 20:19:38
David Wilder wrote:
The definitions for page->flags in crash are no longer correct in crash
resulting in incorrect output for the kmem -i command.   The page flags
are currently defined for V22 V24 and one flag for V26.   ; The flag
definitions are changing in the 2.6 kernel often, crash will need to
update these definitions for each 2.6.x.  Yuck! ;   Can we limit the flag
definitions to just a few kernel versions?  Any suggestions on what
versions we should have definitions for?
 
I've long since been keeping up with these, because most
of the hardwired page flag definitions that are #define'd
in memory.c are not used anymore.  For example, there's
this construct in dump_mem_map() which just displays the
hex value:

  if (v22) {
 ;      ...translate hardwired flags...
  } else if (THIS_KERNEL_VERSION > LINUX(2,4,9)) {
 ;      fprintf(fp, "%lx\n", flags);
  } else {
 ;      ...translate old hardwired 2.4 flags...
  }

But there are a few other places that need to know about
specific flags, like PG_reserved and PG_slab for example,
whose bits get determined in vm_init().  Which one has
changed that upsets "kmem -i"?

Dave

 
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilderus.ibm.com
(503)578-3789

--
Crash-utility mailing list
Crash-utilityredhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Need to update page->flags
user name
2006-03-21 22:17:45
Dave Anderson wrote:

> David Wilder wrote:
>
>> The definitions for page->flags in crash are no
longer correct in crash
>> resulting in incorrect output for the kmem -i
command.   The page flags
>> are currently defined for V22 V24 and one flag for
V26.    The flag
>> definitions are changing in the 2.6 kernel often,
crash will need to
>> update these definitions for each 2.6.x.  Yuck!   
Can we limit the flag
>> definitions to just a few kernel versions?  Any
suggestions on what
>> versions we should have definitions for?
>>  
>
> I've long since been keeping up with these, because
most
> of the hardwired page flag definitions that are
#define'd
> in memory.c are not used anymore.  For example,
there's
> this construct in dump_mem_map() which just displays
the
> hex value:
>
>   if (v22) {
>        ...translate hardwired flags...
>   } else if (THIS_KERNEL_VERSION > LINUX(2,4,9)) {
>        fprintf(fp, "%lx\n", flags);
>   } else {
>        ...translate old hardwired 2.4 flags...
>   }
>
> But there are a few other places that need to know
about
> specific flags, like PG_reserved and PG_slab for
example,
> whose bits get determined in vm_init().  Which one has
> changed that upsets "kmem -i"?
>
> Dave
>

I was first looking at PG_slab.  But I now see this bit in
vm_init()

if (VALID_MEMBER(page_pte)) {
                if (THIS_KERNEL_VERSION < LINUX(2,6,0))
                        vt->PG_slab = 10;
                else if (THIS_KERNEL_VERSION >=
LINUX(2,6,0))
                        vt->PG_slab = 7;
        }

This would set the correct value for vt->PG_slab = 7
except that  pte is 
not a member of the struct page so vt->PG_slab=0.

vt->PG_reserved is not getting set in
PG_reserved_flag_init().  But that 
looks like a problem resolving the symbol sys_read.   So in 
dump_mem_map() it is falling back to v24_PG_reserved....

case GET_TOTALRAM_PAGES:
                                if (vt->PG_reserved)
                                        PG_reserved_flag =
vt->PG_reserved;
                                else
                                        PG_reserved_flag =
v22 ?
                                                1 <<
v22_PG_reserved :
                                                1 <<
v24_PG_reserved;
....
That should mess up the calculation for total memory for
kmem -i.  But 
in my case the number is still correct..





-- 
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA 
dwilderus.ibm.com
(503)578-3789

--
Crash-utility mailing list
Crash-utilityredhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )