linux-kernel - Re: Memory management woes - order 1 allocation failures

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, 26 Feb 2010 16:33:16 +0100
From:	Frans Pop <elendil@...net.nl>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Mel Gorman <mel@...net.ie>
Subject: Re: Memory management woes - order 1 allocation failures

On Friday 26 February 2010, Pekka Enberg wrote:
> > Isn't it a bit strange that cache claims so much memory that real
> > processes get into allocation failures?
>
> All of the failed allocations seem to be GFP_ATOMIC so it's not _that_
> strange.

It's still very ugly though. And I would say it should be unnecessary.

> Dunno if anything changed recently. What's the last known good kernel for
> you? 

I've not used that box very intensively in the past, but I first saw the 
allocation failure with aptitude with either .31 or .32. I would be 
extremely surprised if I could reproduce the problem with .30.
And I have done large rsyncs to the box without any problems in the past, 
but that must have been with .24 or so kernels.

It seems likely to me that it's related to all the other swap and 
allocation issues we've been seeing after .30.

Thanks,
FJP
--
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/