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

[Nigel Cunningham <ncunningham@cyclades.com>]

Hi.

On Tue, 2005-08-09 at 15:20, Nick Piggin wrote:
> Nigel Cunningham wrote:
> > Hi Nick et al.
> > 
> > On Tue, 2005-08-09 at 14:59, Nick Piggin wrote:
> 
> >>>Changing the e820 code so it sets PageNosave instead of PageReserved,
> >>>along with a couple of modifications in swsusp itself should get rid of
> >>>the swsusp dependency.
> >>>
> >>
> >>That would work for swsusp, but there are other users that want to
> >>know if a struct page is valid ram (eg. ioremap), so in that case
> >>swsusp would not be able to mess with the flag.
> > 
> > 
> > Um. Mess with which flag? I guess you mean Reserved. I was saying that
> 
> Mess with PageNosave (if that is what we used to denote a struct page
> not pointing to valid RAM).
> 
> Ie. when swsusp allocates its save map (or whatever it calls it), setting
> PageNosave would make other parts of the kernel think the area is not
> valid ram.

Ok. I guess I should have looked, but I thought the suspend
implementations were the only users of Nosave.

> In other words - we can't combine swsusp's PageNosave with our mythical
> PageValidRAM.
> 
> > imaging Reserved going away, so for the short term I'd be meaning making
> > the e820 set both Nosave and Reserved for those pages (which is what the
> > Suspend2 patches do so as to play nicely with swsusp - I don't use
> > Reserved at all).
> > 
> 
> In the short term, PageReserved can stay around - swsusp does still
> work if I hadn't made that clear.

Yeah.

> By the way - how does swsusp2 handle this problem if not using
> PageReserved?

At the places where Reserved is currently set and cleared, I set and
clear Nosave as well. Then I only use Nosave. Swsusp still works fine
(although I have to comment out a bogus bug_on()) and suspend2 can clear
and set additional pages' Nosave flags while it runs (equivalents to
Pavel's nosave_free pages and also pages allocated for checksumming when
I get paranoid).

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/