linux-kernel - Re: [PATCH -mm] swsusp: Improve handling of highmem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200610232125.36680.rjw@sisk.pl>
Date:	Mon, 23 Oct 2006 21:25:36 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Pavel Machek <pavel@....cz>
Cc:	Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mm] swsusp: Improve handling of highmem

Hi,

On Monday, 23 October 2006 17:29, Pavel Machek wrote:
> Hi!
> 
> > > > Currently swsusp saves the contents of highmem pages by copying them to the
> > > > normal zone which is quite inefficient  (eg. it requires two normal pages to be
> > > > used for saving one highmem page).  This may be improved by using highmem
> > > > for saving the contents of saveable highmem pages.
> > > ...
> > > >  include/linux/suspend.h |    9 
> > > >  kernel/power/power.h    |    2 
> > > >  kernel/power/snapshot.c |  841 ++++++++++++++++++++++++++++++++++++------------
> > > >  kernel/power/swap.c     |    2 
> > > >  kernel/power/swsusp.c   |   53 +--
> > > >  kernel/power/user.c     |    2 
> > > >  mm/vmscan.c             |    3 
> > > 
> > > Well, I just hoped that highmem would quietly die out...
> > > 
> > > ...
> > > > +static struct page *alloc_image_page(gfp_t gfp_mask) {
> > > > +	struct page *page;
> > > 
> > > { should go on new line.
> > 
> > Ah, yes, thanks.  I'll fix this later if you don't mind.
> 
> Ok.
> 
> > > >  	memory_bm_position_reset(orig_bm);
> > > >  	memory_bm_position_reset(copy_bm);
> > > >  	do {
> > > >  		pfn = memory_bm_next_pfn(orig_bm);
> > > > -		if (likely(pfn != BM_END_OF_MAP)) {
> 1) ##############################################
> > > > -			struct page *page;
> > > > -			void *src;
> > > > -
> > > > -			page = pfn_to_page(pfn);
> > > > -			src = page_address(page);
> > > > -			page = pfn_to_page(memory_bm_next_pfn(copy_bm));
> > > > -			copy_data_page(page_address(page), src);
> > > > -		}
> > > > +		if (likely(pfn != BM_END_OF_MAP))
> 2) ##############################################
> > > > +			copy_data_page(memory_bm_next_pfn(copy_bm), pfn);
> > > >  	} while (pfn != BM_END_OF_MAP);
> 3) ####################################
> > > >  }
> > > 
> > > While(1) and "if (pfn != BM_END_OF_MAP) { ...break; } ? Why do you
> > > need to test pfn != BM_END_OF_MAP *three* times?
> > 
> > Why?  It's two times, and I don't like while(1) loops, really.
> 
> I see three of them, and while(1) loop is probably best solution
> here... "Too scared of break; so I copy conditions"? ;-).

But 1) is being dropped! :-)

In fact 2) goes instead of 1) and 3) stays as it was before.

> > > > @@ -1233,6 +1233,9 @@ out:
> > > >  	}
> > > >  	if (!all_zones_ok) {
> > > >  		cond_resched();
> > > > +
> > > > +		try_to_freeze();
> > > > +
> > > >  		goto loop_again;
> > > >  	}
> > > 
> > > What is this?
> > 
> > :-)
> > 
> > This is needed because during the resume there likely are no free pages in the
> > highmem zone which makes kswapd spin forever, but we have to freeze it before
> > the image is restored.
> 
> Could that happen with current code, too? (I'm trying to sense if this
> should be merged now as a separate patch).

Certainly not during the resume.  It may be possible to be triggered during
the suspend (resulting in a suspend failure), but I think that's _extremely_
unlikely.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/