linux-kernel - Re: [Bug #14141] order 2 page allocation failures (generic)

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]

Message-ID: <20091020141423.GH11778@csn.ul.ie>
Date:	Tue, 20 Oct 2009 15:14:24 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Tobias Oetiker <tobi@...iker.ch>
Cc:	Frans Pop <elendil@...net.nl>,
	Pekka Enberg <penberg@...helsinki.fi>,
	David Rientjes <rientjes@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Karol Lewandowski <karol.k.lewandowski@...il.com>,
	Mohamed Abbas <mohamed.abbas@...el.com>,
	"John W. Linville" <linville@...driver.com>, linux-mm@...ck.org,
	jens.axboe@...cle.com
Subject: Re: [Bug #14141] order 2 page allocation failures (generic)

On Tue, Oct 20, 2009 at 03:50:12PM +0200, Tobias Oetiker wrote:
> Hi Mel,
> 
> Today Mel Gorman wrote:
> 
> > On Tue, Oct 20, 2009 at 02:58:53PM +0200, Tobias Oetiker wrote:
> > > you are saing that the problem might be even older ?
> > >
> > > we do have 8GB ram and 16 GB swap, so it should not fail to allocate all that
> > > often
> > >
> > > top - 14:58:34 up 19:54,  6 users,  load average: 2.09, 1.94, 1.97
> > > Tasks: 451 total,   1 running, 449 sleeping,   0 stopped,   1 zombie
> > > Cpu(s):  3.5%us, 15.5%sy,  2.0%ni, 72.2%id,  6.5%wa,  0.1%hi,  0.3%si,  0.0%st
> > > Mem:   8198504k total,  7599132k used,   599372k free,  1212636k buffers
> > > Swap: 16777208k total,    83568k used, 16693640k free,   610136k cached
> > >
> >
> > High-order atomic allocations of the type you are trying at that frequency
> > were always a very long shot. The most likely outcome is that something
> > has changed that means a burst of allocations trigger an allocation failure
> > where as before processes would delay long enough for the system not to notice.
> >
> > 1. Have MTU settings changed?
> 
> no not to my knowledge
> 
> > 2. As order-5 allocations are required to succeed, I'm surprised in a
> >    sense that there are only 5 failures because it implies the machine is
> >    actually recovering and continueing on as normal. Can you think of what
> >    happens in the morning that causes a burst of allocations to occur?
> 
> the burts occur all day while the machine is in use ... its just
> that I was  writing this at noon so only the morning had passed. So
> I compared things to the day before ...
> 

Over the course of a day, how many would you see? By and large, it seems
that the problem yourself and Frans are similar except his is a lot more
severe.

> > 3. Other than the failures, have you noticed any other problems with the
> >    machine or does it continue along happily?
> 
> The machine seems to be fine.
> 
> > 4. Does the following patch help by any chance?
> 
> should I try this on vanilla 2.6.31.4 or ontop of your previous
> patch?
> 

Try on top of vanilla 2.6.31.4 first plase and if failures still occur,
then on top of the previous patch.

> we are running virtualbox 3.0.8 on this machine, virtualbox is using
> the physical network interface in bridge mode access the network.
> Could this have something todo with the problem ?
> 

I do not know for sure. I'm assuming the configuration is the same on
both kernels so it's unlikely to be the issue.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
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/