KAMEZAWA Hiroyuki wrote:
> On Sun, 07 Jun 2009 11:35:27 -0500
> Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote:
>
>> Pekka Enberg wrote:
>>> On Sun, Jun 7, 2009 at 5:19 PM, Rik van Riel <riel@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe kernel-testers" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
