linux-kernel - Re: [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: [linux-pm] 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:	Fri, 22 Jan 2010 10:31:32 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	kosaki.motohiro@...fujitsu.com,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	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)

> > Probably we have multiple option. but I don't think GFP_NOIO is good
> > option. It assume the system have lots non-dirty cache memory and it isn't
> > guranteed.
> 
> Basically nothing is guaranteed in this case.  However, does it actually make
> things _worse_?  

Hmm..
Do you mean we don't need to prevent accidental suspend failure?
Perhaps, I did misunderstand your intention. If you think your patch solve
this this issue, I still disagree. but If you think your patch mitigate
the pain of this issue, I agree it. I don't have any reason to oppose your
first patch.

> What _exactly_ does happen without the $subject patch if the
> system doesn't have non-dirty cache memory and someone makes a GFP_KERNEL
> allocation during suspend?

Page allocator prefer to spent lots time for reclaimable memory searching than
returning NULL. IOW, it can spent time few second if it doesn't have
reclaimable memory.
In typical case, OOM killer forcely make enough free memory if the system
don't have any memory. But under suspending time, oom killer is disabled.
So, if the caller (probably drivers) call alloc >1000times, the system
spent lots seconds.

In this case, GFP_NOIO doesn't help. slowness behavior is caused by
freeable memory search, not slow i/o.

However, if strange i/o device makes any i/o slowness, GFP_NOIO might help.
In this case, please don't ask me about i/o thing. I don't know ;)

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