From mboxrd@z Thu Jan 1 00:00:00 1970 From: Larry Finger Subject: Re: [Bug #13319] Page allocation failures with b43 and p54usb Date: Mon, 08 Jun 2009 12:20:15 -0500 Message-ID: <4A2D484F.3090209@lwfinger.net> References: <4A2BBC30.2030300@lwfinger.net> <84144f020906070640rf5ab14nbf66d3ca7c97675f@mail.gmail.com> <4A2BCC6F.8090004@redhat.com> <84144f020906070732l31786156r5d9753a0cabfde79@mail.gmail.com> <4A2BEC4F.6020908@lwfinger.net> <20090608173219.0588af26.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; q=dns/txt; d=att.net; s=dkim01; i=larry.finger-fOdFMYwuEsI@public.gmane.org; a=rsa-sha256; c=relaxed/relaxed; t=1244481621; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date: Message-ID; bh=cpgnBBekXA29r2aU0sVBnx4UYEfTvVlQzC3N11OeszQ=; b=n7W 7BlRBk/P0eYpAqMQTy8f4is4MgQ7RGXbZLJCBdfLewZKRYE4BCHlrRTahZHb6fmh0ww VzTYS0oatWQTnGCw== In-Reply-To: <20090608173219.0588af26.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: KAMEZAWA Hiroyuki Cc: Pekka Enberg , Rik van Riel , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Johannes Berg , Andrew Morton , KOSAKI Motohiro , Mel Gorman KAMEZAWA Hiroyuki wrote: > On Sun, 07 Jun 2009 11:35:27 -0500 > Larry Finger wrote: > >> Pekka Enberg wrote: >>> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel wrote: >>>> That is a very strange trace. The Mem-Info indicates >>>> that the system has more than enough memory free, and >>>> also enough memory in higher-order free blocks. >>>> >>>> This would indicate a bug somewhere in the page >>>> allocator - this memory should have been given to this >>>> allocation request. >>> Aha, I always have difficulties deciphering the traces. But lets >>> invite Mel to the party then! >> I'm happy to see some action on this problem. As usual, I'm happy to >> test patches and/or provide diagnostic output. >> > One question. > > Did your system fragmented in same way as to this > (see DMA32, 10052 of order-0 pages) in older kernel ? I think you can check > fragmentation status via /proc/buddyinfo. > = > kernel: Node 0 DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 1*128kB 2*256kB 0*512kB > 1*1024kB 0*2048kB 0*4096kB = 2100kB > kernel: Node 0 DMA32: 10062*4kB 1*8kB 1*16kB 0*32kB 1*64kB 1*128kB 0*256kB > 1*512kB 0*1024kB 0*2048kB 0*4096kB = 40976kB > == The current system has not been up very long and does not show the fragmentation: finger@larrylap:~/wireless-testing> cat /proc/buddyinfo Node 0, zone DMA 4 5 4 2 4 1 2 0 1 0 0 Node 0, zone DMA32 261 78 46 55 61 54 37 17 14 12 262 After I did a git pull and a kernel build with the sources on an NFS-mounted volume, the fragmentation increased: Node 0, zone DMA 4 5 4 2 4 1 2 0 1 0 0 Node 0, zone DMA32 2213 1924 1292 705 285 81 25 8 5 4 141 After a git pull and a kernel build on a second NFS-mounted tree: Node 0, zone DMA 4 5 4 2 4 1 2 0 1 0 0 Node 0, zone DMA32 3127 3058 1989 756 401 142 56 14 5 3 12 Larry