From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb Date: Mon, 08 Jun 2009 09:20:23 -0400 Message-ID: <4A2D1017.6010308@redhat.com> References: <4A2BBC30.2030300@lwfinger.net> <84144f020906070640rf5ab14nbf66d3ca7c97675f@mail.gmail.com> <4A2BCC6F.8090004@redhat.com> <84144f020906070732l31786156r5d9753a0cabfde79@mail.gmail.com> <20090608101739.GA15377@csn.ul.ie> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090608101739.GA15377-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Mel Gorman Cc: Pekka Enberg , Larry Finger , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Johannes Berg , Andrew Morton , KOSAKI Motohiro , KAMEZAWA Hiroyuki Mel Gorman wrote: > We've encountered this before and the conclusion was that the current > adjustments for watermark calculations of high-order allocations is right, > or at least there is no better alternative. In other words, the page > allocator in this instance is behaving as expected. Do we want to > revisit that discussion as to whether the watermark calculations for > high-order allocation should change? I think we'll reach the same > conclusion or at least decide that allowing the order-1 atomic > allocation to succeed here would just postpone the problem. It would not just postpone the problem, it would also bring the system closer to a state where kswapd does something about the order-1 free areas. This might postpone the problem indefinately. Currently the system fails early, without kswapd kicking in and freeing new order-1 areas. -- All rights reversed.