Re: page flags ?

On Thu, 2005-05-19 at 17:03, Martin J. Bligh wrote:

--On Thursday, May 19, 2005 16:34:27 -0700 Badari Pulavarty [off-list ref] wrote:

quoted

On Thu, 2005-05-19 at 15:53, Andrew Morton wrote:

quoted

Badari Pulavarty [off-list ref] wrote:

quoted

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

kmap() already sucks.

I thought so, but wanted to be explicit.

quoted

quoted

 -#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 ;-)

quoted

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>