page flags ?

page flags ?

[Badari Pulavarty]

Does anyone know what this page-flag is used for ? I see some
references to this in AFS. 

Is it possible for me to use this for my own use in ext3 ? 
(like delayed allocations ?) Any generic routines/VM stuff
expects me to use this only for a specific purpose ?

#define PG_fs_misc               9      /* Filesystem specific bit */

Thanks,
Badari

Re: page flags ?

[Andrew Morton]

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> Does anyone know what this page-flag is used for ? I see some
> references to this in AFS. 
> 
> Is it possible for me to use this for my own use in ext3 ? 
> (like delayed allocations ?) Any generic routines/VM stuff
> expects me to use this only for a specific purpose ?
> 
> #define PG_fs_misc               9      /* Filesystem specific bit */
> 

It's identical to PG_checked, added by David Howells'
provide-a-filesystem-specific-syncable-page-bit.patch

IIRC we decided to expand the definition of PG_checked to mean
"a_ops-private, fs-defined page flag".  I guess if/when that patch is
merged we'll do a kernel-wide s/PG_checked/PG_fs_misc/.

And ext3 is already using that flag.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: page flags ?

[Badari Pulavarty]

On Wed, 2005-05-18 at 14:56, Andrew Morton wrote:
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > Does anyone know what this page-flag is used for ? I see some
> > references to this in AFS. 
> > 
> > Is it possible for me to use this for my own use in ext3 ? 
> > (like delayed allocations ?) Any generic routines/VM stuff
> > expects me to use this only for a specific purpose ?
> > 
> > #define PG_fs_misc               9      /* Filesystem specific bit */
> > 
> 
> It's identical to PG_checked, added by David Howells'
> provide-a-filesystem-specific-syncable-page-bit.patch
> 
> IIRC we decided to expand the definition of PG_checked to mean
> "a_ops-private, fs-defined page flag".  I guess if/when that patch is
> merged we'll do a kernel-wide s/PG_checked/PG_fs_misc/.
> 
> And ext3 is already using that flag.

:(

Is it possible to get yet another PG_fs_specific flag ? 
Reasons for it are:

	- I need this for supporting delayed allocation on ext3. Me, Ted
	  and Suparna thought about it for a while to see we can 
	  workaround it. So far, I haven't found a clean way.

	- useful for other folks currently overloading page->private
	  for this purpose. May be then, we can make most filesystems
	  use mpage routines (since they assume page->private is for
	  bufferheads ?)

Thanks,
Badari

Re: page flags ?

[Andrew Morton]

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> Is it possible to get yet another PG_fs_specific flag ? 

Anything's possible ;)

How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.

> Reasons for it are:
> 
> 	- I need this for supporting delayed allocation on ext3.

Why?

Re: page flags ?

[Bryan Henderson]

By the way, shouldn't these really be PG_as_misc/PG_as_specific as opposed 
to PG_fs_misc ...?

In theory, an address space can be something other than a file cache, and 
there's no reason any arbitrary adress_space_ops shouldn't have its own 
private flags.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

Re: page flags ?

[Badari Pulavarty]

On Wed, 2005-05-18 at 16:23, Andrew Morton wrote:
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > Is it possible to get yet another PG_fs_specific flag ? 
> 
> Anything's possible ;)
> 
> How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.

Depends on whom you ask :) CKRM folks are using one/few, 
Hotplug memory guys are using one... :( I lost track..

> 
> > Reasons for it are:
> > 
> > 	- I need this for supporting delayed allocation on ext3.
> 
> Why?
> 

I think, I explained you earlier.. But let me refresh your memory.


In order to do delayed allocation, we "reserve" (not same reservation
the code) a block in prepare/commit and do the allocation in
writepage/writepages.  Unfortunately, mapped writes directly come into
writepage without making a reservation. In order to guarantee that
write() succeeds, I need a way to indicate if the "page" has made
a reservation or not. I was hoping to use a page->flag to do this.
That way I don't have to touch page->private like Alex's code and
get away using mpage routines, instead of having my own.


Thanks,
Badari

Re: page flags ?

[Chandra Seetharaman]

On Wed, May 18, 2005 at 05:09:29PM -0700, Badari Pulavarty wrote:
> On Wed, 2005-05-18 at 16:23, Andrew Morton wrote:
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > Is it possible to get yet another PG_fs_specific flag ? 
> > 
> > Anything's possible ;)
> > 
> > How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.
> 
> Depends on whom you ask :) CKRM folks are using one/few, 

CKRM used one bit... getting rid of it..

> Hotplug memory guys are using one... :( I lost track..
> 
> > 
> > > Reasons for it are:
> > > 
> > > 	- I need this for supporting delayed allocation on ext3.
> > 
> > Why?
> > 
> 
> I think, I explained you earlier.. But let me refresh your memory.
> 
> 
> In order to do delayed allocation, we "reserve" (not same reservation
> the code) a block in prepare/commit and do the allocation in
> writepage/writepages.  Unfortunately, mapped writes directly come into
> writepage without making a reservation. In order to guarantee that
> write() succeeds, I need a way to indicate if the "page" has made
> a reservation or not. I was hoping to use a page->flag to do this.
> That way I don't have to touch page->private like Alex's code and
> get away using mpage routines, instead of having my own.
> 
> 
> Thanks,
> Badari
> 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------

Re: page flags ?

[Dave Hansen]

On Wed, 2005-05-18 at 17:09 -0700, Badari Pulavarty wrote:
> On Wed, 2005-05-18 at 16:23, Andrew Morton wrote:
> > Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > Is it possible to get yet another PG_fs_specific flag ? 
> > 
> > Anything's possible ;)
> > 
> > How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.
> 
> Depends on whom you ask :) CKRM folks are using one/few, 
> Hotplug memory guys are using one... :( I lost track..

Don't worry about me :)  There are a billion different ways to do what I
currently need that bit for.  It's just the easiest, and I'll code
something up that doesn't steal space from everyone else before I submit
it.

-- Dave

Re: page flags ?

[Andy Whitcroft]

Andrew Morton wrote:

> Anything's possible ;)
> 
> How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.

The short answer is that on 32 bit architectures there are 24 bits
allocated to general page flags, page-flags.h indicates that 21 are
currently assigned so assuming it is accurate there are currently 3 bits
free.

Perhaps this my cue to chip in and provide some commentry on the
zonetable patches.

Before the zonetable patches the flags were essentially split into two
sections, the top 8 bits for the NODEZONE 'pointer' and the remaining 24
bits for page flags.  The NODEZONE bits were further subdivided into
NODE and ZONE.  For i386 for instance 2 bits were allocated to ZONE and
6 bits for NODE.  There was no flexibility in layout.

	32           24             0
	| NODE | ZONE | ... | FLAGS |

The zonetable patches came out of the need to add a new field into this
area; the SECTION field for the SPARSEMEM work.  This meant that we
wanted to be able to specify both the size and packing order for these
fields.  This would allow us to specify unused fields as 0 width to
reclaim precious bits.  It would also allow us to optimise order such
that the key performance critical mapping from page to struct zone
pointer was efficient to extract (a single shift).  This key is commonly
NODE,ZONE but may be SECTION,ZONE when short of space, the two fields in
use need to be contigious and preferably at the left.

The zonetable patches work by allowing us to simply define the width of
each field we are using and the order of those fields.  Field widths are
defined by the *_WIDTH definitions, these are either the architecture
specific default width *_SHIFT or 0 where the field is not required (for
instance if not used by the current memory model).  The field order is
defined by the relationships between the *_PGOFF definitions, packing
them from the left of the field.  Access to these fields is via the
*_PGSHIFT and *_MASK defines.  Care is taken to ensure that they are
valid for a zero with field.  The ZONETABLE_PGSHIFT and _MASK define the
combined key field used to locate the struct zone for this page.

Overall the allocation to the NODEZONE area is defined to be the highest
order FLAGS_RESERVED bits of the flags word (8 on 32 bit architectures,
and 32 on 64 bit).  The overall allocation to this field is unchanged.

-apw

Re: page flags ?

[Andrew Morton]

Andy Whitcroft <apw@shadowen.org> wrote:
>
>  > How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.
> 
>  The short answer is that on 32 bit architectures there are 24 bits
>  allocated to general page flags, page-flags.h indicates that 21 are
>  currently assigned so assuming it is accurate there are currently 3 bits
>  free.

Yipes, I didn't realise we were that close.

We can reclaim PG_highmem, use page_zone(page)->highmem

We can probably reclaim PG_slab

We can conceivably reclaim PG_swapcache, although that stuff got ugly.

Would dearly love to nuke PG_reserved, but everybody's scared of that ;)

PG_uncached is currently ia64-only and could conceivably be moved to bit
32, except there are rumours that arm might want to use it someday.

It's a bit irritating that swsusp uses two flags.

I don't see any other low-hanging fruit there.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: page flags ?

[Nikita Danilov]

Andrew Morton writes:
 > Andy Whitcroft <apw@shadowen.org> wrote:
 > >
 > >  > How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.
 > > 
 > >  The short answer is that on 32 bit architectures there are 24 bits
 > >  allocated to general page flags, page-flags.h indicates that 21 are
 > >  currently assigned so assuming it is accurate there are currently 3 bits
 > >  free.
 > 
 > Yipes, I didn't realise we were that close.
 > 
 > We can reclaim PG_highmem, use page_zone(page)->highmem
 > 
 > We can probably reclaim PG_slab
 > 
 > We can conceivably reclaim PG_swapcache, although that stuff got ugly.
 > 
 > Would dearly love to nuke PG_reserved, but everybody's scared of that ;)
 > 
 > PG_uncached is currently ia64-only and could conceivably be moved to bit
 > 32, except there are rumours that arm might want to use it someday.
 > 
 > It's a bit irritating that swsusp uses two flags.
 > 
 > I don't see any other low-hanging fruit there.

Things like PG_uptodate and PG_error can be moved to the radix-tree tags
after checking that they are used only for pages in the mapping, which
seems to be the case.

 > --

Nikita.

Re: page flags ?

[Badari Pulavarty]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Thu, 2005-05-19 at 04:11, Andrew Morton wrote:
> Andy Whitcroft <apw@shadowen.org> wrote:
> >
> >  > How many bits are spare now?  ZONETABLE_PGSHIFT hurts my brain.
> > 
> >  The short answer is that on 32 bit architectures there are 24 bits
> >  allocated to general page flags, page-flags.h indicates that 21 are
> >  currently assigned so assuming it is accurate there are currently 3 bits
> >  free.
> 
> Yipes, I didn't realise we were that close.
> 
> We can reclaim PG_highmem, use page_zone(page)->highmem

Your wish is my command :)

I am worried about the overhead this might add to kmap/kunmap().

Thanks,
Badari



[-- Attachment #2: PG_highmem-remove.patch --]
[-- Type: text/plain, Size: 5454 bytes --]

Patch to remove PG_highmem from page->flags.

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
 arch/frv/mm/init.c         |    1 -
 arch/i386/mm/init.c        |    1 -
 arch/mips/mm/init.c        |    1 -
 arch/ppc/mm/init.c         |    1 -
 arch/sparc/mm/init.c       |    1 -
 arch/um/kernel/mem.c       |    1 -
 fs/reiser4/page_cache.c    |    3 +--
 include/linux/page-flags.h |    4 ++--
 8 files changed, 3 insertions(+), 10 deletions(-)
diff -X dontdiff -Narup linux-2.6.12-rc4.org/arch/frv/mm/init.c linux-2.6.12-rc4/arch/frv/mm/init.c
--- linux-2.6.12-rc4.org/arch/frv/mm/init.c	2005-05-06 22:20:31.000000000 -0700
+++ linux-2.6.12-rc4/arch/frv/mm/init.c	2005-05-19 03:43:27.266433184 -0700
@@ -169,7 +169,6 @@ void __init mem_init(void)
 		struct page *page = &mem_map[pfn];
 
 		ClearPageReserved(page);
-		set_bit(PG_highmem, &page->flags);
 		set_page_count(page, 1);
 		__free_page(page);
 		totalram_pages++;
diff -X dontdiff -Narup linux-2.6.12-rc4.org/arch/i386/mm/init.c linux-2.6.12-rc4/arch/i386/mm/init.c
--- linux-2.6.12-rc4.org/arch/i386/mm/init.c	2005-05-17 02:27:11.350562312 -0700
+++ linux-2.6.12-rc4/arch/i386/mm/init.c	2005-05-19 03:43:43.178014256 -0700
@@ -269,7 +269,6 @@ void __init one_highpage_init(struct pag
 {
 	if (page_is_ram(pfn) && !(bad_ppro && page_kills_ppro(pfn))) {
 		ClearPageReserved(page);
-		set_bit(PG_highmem, &page->flags);
 		set_page_count(page, 1);
 		__free_page(page);
 		totalhigh_pages++;
diff -X dontdiff -Narup linux-2.6.12-rc4.org/arch/mips/mm/init.c linux-2.6.12-rc4/arch/mips/mm/init.c
--- linux-2.6.12-rc4.org/arch/mips/mm/init.c	2005-05-06 22:20:31.000000000 -0700
+++ linux-2.6.12-rc4/arch/mips/mm/init.c	2005-05-19 03:43:57.457843392 -0700
@@ -232,7 +232,6 @@ void __init mem_init(void)
 #ifdef CONFIG_LIMITED_DMA
 		set_page_address(page, lowmem_page_address(page));
 #endif
-		set_bit(PG_highmem, &page->flags);
 		set_page_count(page, 1);
 		__free_page(page);
 		totalhigh_pages++;
diff -X dontdiff -Narup linux-2.6.12-rc4.org/arch/ppc/mm/init.c linux-2.6.12-rc4/arch/ppc/mm/init.c
--- linux-2.6.12-rc4.org/arch/ppc/mm/init.c	2005-05-17 02:27:11.400554712 -0700
+++ linux-2.6.12-rc4/arch/ppc/mm/init.c	2005-05-19 03:44:18.800598800 -0700
@@ -459,7 +459,6 @@ void __init mem_init(void)
 			struct page *page = mem_map + pfn;
 
 			ClearPageReserved(page);
-			set_bit(PG_highmem, &page->flags);
 			set_page_count(page, 1);
 			__free_page(page);
 			totalhigh_pages++;
diff -X dontdiff -Narup linux-2.6.12-rc4.org/arch/sparc/mm/init.c linux-2.6.12-rc4/arch/sparc/mm/init.c
--- linux-2.6.12-rc4.org/arch/sparc/mm/init.c	2005-05-06 22:20:31.000000000 -0700
+++ linux-2.6.12-rc4/arch/sparc/mm/init.c	2005-05-19 03:44:40.526295992 -0700
@@ -384,7 +384,6 @@ void map_high_region(unsigned long start
 		struct page *page = pfn_to_page(tmp);
 
 		ClearPageReserved(page);
-		set_bit(PG_highmem, &page->flags);
 		set_page_count(page, 1);
 		__free_page(page);
 		totalhigh_pages++;
diff -X dontdiff -Narup linux-2.6.12-rc4.org/arch/um/kernel/mem.c linux-2.6.12-rc4/arch/um/kernel/mem.c
--- linux-2.6.12-rc4.org/arch/um/kernel/mem.c	2005-05-06 22:20:31.000000000 -0700
+++ linux-2.6.12-rc4/arch/um/kernel/mem.c	2005-05-19 03:45:00.200305088 -0700
@@ -53,7 +53,6 @@ static void setup_highmem(unsigned long 
 	for(i = 0; i < highmem_len >> PAGE_SHIFT; i++){
 		page = &mem_map[highmem_pfn + i];
 		ClearPageReserved(page);
-		set_bit(PG_highmem, &page->flags);
 		set_page_count(page, 1);
 		__free_page(page);
 	}
diff -X dontdiff -Narup linux-2.6.12-rc4.org/fs/reiser4/page_cache.c linux-2.6.12-rc4/fs/reiser4/page_cache.c
--- linux-2.6.12-rc4.org/fs/reiser4/page_cache.c	2005-05-17 02:27:19.258360144 -0700
+++ linux-2.6.12-rc4/fs/reiser4/page_cache.c	2005-05-19 03:45:38.432492912 -0700
@@ -744,7 +744,7 @@ print_page(const char *prefix, struct pa
 	}
 	printk("%s: page index: %lu mapping: %p count: %i private: %lx\n",
 	       prefix, page->index, page->mapping, page_count(page), page->private);
-	printk("\tflags: %s%s%s%s %s%s%s %s%s%s %s%s%s\n",
+	printk("\tflags: %s%s%s%s %s%s%s %s%s %s%s%s\n",
 	       page_flag_name(page, PG_locked),
 	       page_flag_name(page, PG_error),
 	       page_flag_name(page, PG_referenced),
@@ -754,7 +754,6 @@ print_page(const char *prefix, struct pa
 	       page_flag_name(page, PG_lru),
 	       page_flag_name(page, PG_slab),
 
-	       page_flag_name(page, PG_highmem),
 	       page_flag_name(page, PG_checked),
 	       page_flag_name(page, PG_reserved),
 
diff -X dontdiff -Narup linux-2.6.12-rc4.org/include/linux/page-flags.h linux-2.6.12-rc4/include/linux/page-flags.h
--- linux-2.6.12-rc4.org/include/linux/page-flags.h	2005-05-17 02:27:20.248209664 -0700
+++ linux-2.6.12-rc4/include/linux/page-flags.h	2005-05-19 03:46:57.214516224 -0700
@@ -61,7 +61,7 @@
 #define PG_active		 6
 #define PG_slab			 7	/* slab debug (Suparna wants this) */
 
-#define PG_highmem		 8
+#define PG_highmem_removed	 8	/* Trying to kill this */
 #define PG_fs_misc		 9	/* Filesystem specific bit */
 #define PG_checked		 9	/* kill me in 2.5.<early>. */
 #define PG_arch_1		10
@@ -216,7 +216,7 @@ extern void __mod_page_state(unsigned of
 #define TestSetPageSlab(page)	test_and_set_bit(PG_slab, &(page)->flags)
 
 #ifdef CONFIG_HIGHMEM
-#define PageHighMem(page)	test_bit(PG_highmem, &(page)->flags)
+#define PageHighMem(page)	is_highmem(page_zone(page))
 #else
 #define PageHighMem(page)	0 /* needed to optimize away at compile time */
 #endif

Re: page flags ?

[Andrew Morton]

Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> I am worried about the overhead this might add to kmap/kunmap().
> 

kmap() already sucks.

>  -#define PG_highmem		 8
>  +#define PG_highmem_removed	 8	/* Trying to kill this */

I thnik I'll just nuke this.

Re: page flags ?

[Badari Pulavarty]

On Thu, 2005-05-19 at 15:53, Andrew Morton wrote:
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > I am worried about the overhead this might add to kmap/kunmap().
> > 
> 
> kmap() already sucks.
> 

I thought so, but wanted to be explicit.

> >  -#define PG_highmem		 8
> >  +#define PG_highmem_removed	 8	/* Trying to kill this */
> 
> I thnik I'll just nuke this.

Yep. I was just trying to be nice - if some one gets a compile failure,
i wanted them to know that "we are trying to remove it, justify your
case".

BTW, I tried to kill PG_slab. Other than catching error conditions
with memory freeing, there are few users of it
 
	-  show_mem(): to show how much memory stuck in slab easily.
	-  kobjsize()
Thanks,
Badari

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: page flags ?

[Badari Pulavarty]

On Thu, 2005-05-19 at 17:03, Martin J. Bligh wrote:
> --On Thursday, May 19, 2005 16:34:27 -0700 Badari Pulavarty <pbadari@us.ibm.com> wrote:
> 
> > On Thu, 2005-05-19 at 15:53, Andrew Morton wrote:
> >> Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >> > 
> >> > I am worried about the overhead this might add to kmap/kunmap().
> >> > 
> >> 
> >> kmap() already sucks.
> >> 
> > 
> > I thought so, but wanted to be explicit.
> > 
> >> >  -#define PG_highmem		 8
> >> >  +#define PG_highmem_removed	 8	/* Trying to kill this */
> >> 
> >> I thnik I'll just nuke this.
> > 
> > Yep. I was just trying to be nice - if some one gets a compile failure,
> > i wanted them to know that "we are trying to remove it, justify your
> > case".
> 
> /* #define PG_highmem		 8         Dead */ 
> 
> would work ;-)
> 
> > BTW, I tried to kill PG_slab. Other than catching error conditions
> > with memory freeing, there are few users of it
> >  
> > 	-  show_mem(): to show how much memory stuck in slab easily.
> > 	-  kobjsize()
> 
> Is really useful to be able to trace down exactly what mem is in slab,
> and otherwise were memory came from / leaked to. I spose it could could
> be a debug option, but seems a bit sad if we don't need the space yet.
> /proc/meminfo gets it from per cpu page_state, but is nice to have
> a double check.

I agree. I like that "memory stuck in slab" info too :)
Shall we wait till we really really need bits in page->flags ?
Hopefully, by then we will all be 64-bit and life would be wonderful :)

Thanks,
Badari

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: page flags ?

[Martin J. Bligh]

--On Thursday, May 19, 2005 16:34:27 -0700 Badari Pulavarty <pbadari@us.ibm.com> wrote:

> On Thu, 2005-05-19 at 15:53, Andrew Morton wrote:
>> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>> > 
>> > I am worried about the overhead this might add to kmap/kunmap().
>> > 
>> 
>> kmap() already sucks.
>> 
> 
> I thought so, but wanted to be explicit.
> 
>> >  -#define PG_highmem		 8
>> >  +#define PG_highmem_removed	 8	/* Trying to kill this */
>> 
>> I thnik I'll just nuke this.
> 
> Yep. I was just trying to be nice - if some one gets a compile failure,
> i wanted them to know that "we are trying to remove it, justify your
> case".

/* #define PG_highmem		 8         Dead */ 

would work ;-)

> BTW, I tried to kill PG_slab. Other than catching error conditions
> with memory freeing, there are few users of it
>  
> 	-  show_mem(): to show how much memory stuck in slab easily.
> 	-  kobjsize()

Is really useful to be able to trace down exactly what mem is in slab,
and otherwise were memory came from / leaked to. I spose it could could
be a debug option, but seems a bit sad if we don't need the space yet.
/proc/meminfo gets it from per cpu page_state, but is nice to have
a double check.

M.

Re: page flags ?

[Martin J. Bligh]

>> > BTW, I tried to kill PG_slab. Other than catching error conditions
>> > with memory freeing, there are few users of it
>> >  
>> > 	-  show_mem(): to show how much memory stuck in slab easily.
>> > 	-  kobjsize()
>> 
>> Is really useful to be able to trace down exactly what mem is in slab,
>> and otherwise were memory came from / leaked to. I spose it could could
>> be a debug option, but seems a bit sad if we don't need the space yet.
>> /proc/meminfo gets it from per cpu page_state, but is nice to have
>> a double check.
> 
> I agree. I like that "memory stuck in slab" info too :)
> Shall we wait till we really really need bits in page->flags ?
> Hopefully, by then we will all be 64-bit and life would be wonderful :)

Would be nicer not to kill them until we need ... perhaps they could be
commented as to their potential demise? Then the debug ones could be
wrapped in something else, at least, and made available on 64 bit only
(when it comes to that ...)

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>