linux-kernel - Re: [linux-pm] [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: Memory allocations in .suspend became very unreliable)

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Jan 2010 21:59:25 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Oliver Neukum <oliver@...kum.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-mm" <linux-mm@...ck.org>,
	linux-pm@...ts.linux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-pm] [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: Memory allocations in .suspend became very unreliable)

On Monday 18 January 2010, Alan Stern wrote:
> On Mon, 18 Jan 2010, Oliver Neukum wrote:
> 
> > Am Montag, 18. Januar 2010 00:00:23 schrieb Rafael J. Wysocki:
> > > On Sunday 17 January 2010, Benjamin Herrenschmidt wrote:
> > > > On Sun, 2010-01-17 at 14:27 +0100, Rafael J. Wysocki wrote:
> > > ...
> > > > However, it's hard to deal with the case of allocations that have
> > > > already started waiting for IOs. It might be possible to have some VM
> > > > hook to make them wakeup, re-evaluate the situation and get out of that
> > > > code path but in any case it would be tricky.
> > > 
> > > In the second version of the patch I used an rwsem that made us wait for these
> > > allocations to complete before we changed gfp_allowed_mask.
> > 
> > This will be a very, very hot semaphore. What's the impact on performance?
> 
> Can it be replaced with something having lower overhead, such as SRCU?

I'm not sure about that.  In principle SRCU shouldn't be used if the reader can
sleep unpredictably long and the memory allocation sutiation is one of these.

Rafael
--
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/