[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201001201231.17540.oliver@neukum.org>
Date: Wed, 20 Jan 2010 12:31:17 +0100
From: Oliver Neukum <oliver@...kum.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Bastien ROUCARIES <roucaries.bastien@...il.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Maxim Levitsky <maximlevitsky@...il.com>,
linux-pm@...ts.linux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
"linux-mm" <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: [linux-pm] Memory allocations in .suspend became very unreliable)
Am Mittwoch, 20. Januar 2010 00:17:51 schrieb Benjamin Herrenschmidt:
> On Tue, 2010-01-19 at 10:04 +0100, Bastien ROUCARIES wrote:
> > Instead of masking bit could we only check if incompatible flags are
> > used during suspend, and warm deeply. Call stack will be therefore
> > identified, and we could have some metrics about such problem.
> >
> > It will be a debug option like lockdep but pretty low cost.
>
> I still believe it would just be a giant can of worms to require every
> call site of memory allocators to "know" whether suspend has been
> started or not.... Along the same reasons why we added that stuff for
> boot time allocs.
But we have the freezer. So generally we don't require that knowledge.
We can expect no normal IO to happen.
The question is in the suspend paths. We never may use anything
but GFP_NOIO (and GFP_ATOMIC) in the suspend() path. We can
take care of that requirement in the allocator only if the whole system
is suspended. As soon as a driver does runtime power management,
it is on its own.
Regards
Oliver
--
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/
Powered by blists - more mailing lists