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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/