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

Rafael J. Wysocki
2005-08-13T07:02:58Z

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"