Re: [RFC][patch 0/2] mm: remove PageReserved

[Rafael J. Wysocki]

On Saturday, 13 of August 2005 01:04, Daniel Phillips wrote:
> On Saturday 13 August 2005 08:20, Rafael J. Wysocki wrote:
> > On Friday, 12 of August 2005 21:56, Daniel Phillips wrote:
> > > I still don't see why you can't lift your flags up into the VMA.  The
> > > rmap mechanism is there precisely to let you get from the physical page
> > > to the users and user data, including VMAs.
> >
> > I'm not sure if I understand the issue, but swsusp works on a different
> > level. It only needs to figure out which physical pages, as represented by
> > struct page objects, should be saved to swap before suspend.  We browse all
> > zones (once) and create a list of page frames that should be saved on the
> > basis of the contents of the struct page objects alone.  IMHO if we needed
> > to use any additional mechanisms here, it would be less efficient than just
> > checking the page flags.
> 
> Isn't that what hash tables are for?  It seems to me obvious that you don't 
> absolutely need to reserve page flag bits, but you think this is better, 
> maybe enough faster to make a perceptible difference.  How about testing with 
> a hash table?  If it dims the lights then you have all the argument you need.
> 
> Admittedly, page flags have not gotten really tight just yet, and this is 
> something you can change later if they do become tight.  But it would be very 
> nice to know just which of those page flags are really needed (like uptodate) 
> versus which are just there for convenience.  I think yours fall in the 
> latter category.

Well, I think we can do without PG_nosave in swsusp, although it would require
a considerable effort to remove it.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/