thrashing 2.6 ameslab

[Anton Blanchard]

Hi,

I just got the following WARN_ON when pounding the machine with
bash-shared-mappings. Its part of the tlb flush rework. Paul originally
had something in there to recognise the mm had changed and to fix it
up silently.

I changed it to WARN_ON thinking it shouldnt occur normally (an mm
changing in the middle of a batch). However looking at this trace I guess
it can. Looks like we encountered memory pressure in copy_page_range
and ended up scanning pages doing page_referenced.

The problem is, copy_page_range is in the middle of a tlb batch...

I'll restore the silent flush in arch/ppc64/mm/tlb.c

Anton

Badness in hpte_update at arch/ppc64/mm/tlb.c:71
Call Trace:
[c0000000000a32cc] .page_referenced+0x10c/0x25c
[c000000000095a14] .refill_inactive_zone+0xa7c/0xb2c
[c000000000095b60] .shrink_zone+0x9c/0xd4
[c000000000095d04] .shrink_caches+0x16c/0x194
[c000000000095e28] .try_to_free_pages+0xfc/0x224
[c00000000008a29c] .__alloc_pages+0x254/0x438
[c00000000008a4b4] .__get_free_pages+0x34/0x80
[c00000000008f10c] .cache_grow+0x158/0x528
[c00000000008f7c4] .cache_alloc_refill+0x2e8/0x398
[c00000000008fc7c] .kmem_cache_alloc+0xac/0xc0
[c00000000009cec0] .__pmd_alloc+0x60/0x14c
[c000000000098b4c] .copy_page_range+0x690/0x768
[c000000000058948] .copy_mm+0x62c/0x730
[c000000000059920] .copy_process+0x71c/0xfd4
[c00000000005a21c] .do_fork+0x44/0x210
[c000000000016ba8] .sys_fork+0x28/0x40
[c0000000000117d4] .ret_from_syscall_1+0x0/0xa4

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/