Re: [PATCH][Fix] Fix Bug #4959 (take 2)

[Pavel Machek <pavel@suse.cz>]

Hi!

> > I do not really like new exports from swsusp.c, but I'm afraid
> > there's no way around.
> 
> Well, there is one, if we use a static buffer, as you propose, since
> in that case we will not need get_usable_pages() etc. outside of
> swsusp.c.  The drawback of this, however, is that we will limit the
> size of RAM for which it is possible to suspend (we need at least 1 page
> for the PGD, 1 page for a PUD plus as many pages as there are GBs of
> RAM for PMDs).  If we want to cover the huge-RAM cases, the buffer will
> be too large for the average case, but otherwise some boxes will not
> be able to suspend.

1GB per 4K seems pretty much okay.

> > > The following patch fixes Bug #4959.  For this purpose it creates temporary
> > > page translation tables including the kernel mapping (reused) and the direct
> > > mapping (created from scratch) and makes swsusp switch to these tables
> > > right before the image is restored.
> > 
> > Why do you need *two* mappings? Should not just kernel mapping be enough?
> 
> The kernel mapping is for the kernel text.  The direct mapping maps the physical
> RAM linearly to the set of virtual addresses starting at
> PAGE_OFFSET.

Could not you just add phys_to_virt at some strategic place? 

> > Why? Reserve ten pages for them... static char resume_page_tables[10*PAGE_SIZE] does not
> > sound that bad.
> 
> That will allow us to suspend if there's no more that 8GB of RAM in the box.
> Is it acceptable?

I'd say so.

> > > Moreover, such a code would have to be executed on every boot and the
> > > temporary page tables would always be present in memory.
> > 
> > Yep, but I do not see that as a big problem.
> 
> OK
> 
> I can reserve the static buffer (10 pages) in suspend.c and mark it as nosave.
> The code that creates the mappings can stay in suspend.c either except it
> won't need to call get_usable_page() and free_eaten_memory() any more
> (__next_page() can be changed to get pages from the static buffer instead
> of allocating them).  The code can also be simplified a bit, as we assume that
> there will be only one PGD entry in the direct mapping.
> 
> If that sounds good to you, please confirm.

8GB limit seems good to me -- as long as it makes code significantly
simpler. It would be nice if it was <20 lines.
								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address
-
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/