Re: Suspend 2 merge:L 12/51: Disable OOM killer when suspending.

[Pavel Machek]

Hi!

> > > When preparing the image, suspend eats all the memory in sight, both to
> > > reduce the image size and to improve the reliability of our stats (We've
> > > worked hard to make it work reliably under heavy load - 100+). Of course
> > > this can result in the OOM killer being triggered, so this simple test
> > > stops that happening.
> > 
> > andrew's shrink_all_memory should enable you to free memory without
> > hacking OOM killer, no?
> 
> I do use shrink_all_memory, but I also then allocate those pages that
> were freed. We added that when seeking to get Suspend to work well and
> reliably under heavy load. IIRC, the issue was that pages that were
> freed were immediately getting allocated by other programs. Having said
> this, it is a while since I looked at the code for preparing the image.
> I can take a look and confirm my thinking.

How is it possible that other programs steal memory when they are
frozen? That just should not happen.

> > Hmm, yes, something like this migh be usefull for BUG_ONs etc...
> > For consistency, right name is probably in_suspend(void).
> 
> There is a difference; there is sections of time where we're in_suspend
> (test_suspend_state(SUSPEND_RUNNING)) but the freezer isn't on (initial
> set up and cleanup). As far as the OOM killer goes, it probably doesn't
> matter which is used, but I thought it important to point out that
> freezer being on !== in_suspend(). (Freezer could also be on for S3?..
> 'spose you don't care of OOM killer runs then, though). Would you like
> to see in_freezer()?

There was discussion on linux-pm that something like in_freezer()
would be nice for sanity-checks, but don't introduce it just because
of that.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/