Re: page flags ?

[Badari Pulavarty <pbadari@us.ibm.com>]

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>