* OOM-Killer kills too much with 2.6.32.2
@ 2010-01-14 13:15 Roman Jarosz
2010-01-23 0:40 ` David Rientjes
2010-01-25 1:48 ` KOSAKI Motohiro
0 siblings, 2 replies; 52+ messages in thread
From: Roman Jarosz @ 2010-01-14 13:15 UTC (permalink / raw)
To: lkml
Hi,
since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
kills when I do hard disk intensive tasks (mainly in VirtualBox which is
running Windows XP) and IMHO it kills processes even if I have a lot of
free memory.
Is this a known bug? I have self compiled kernel so I can try patches.
Regards
Roman Jarosz
PS. Please CC me.
Jan 7 12:39:27 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 7 12:39:27 kedge kernel: Pid: 1954, comm: X Not tainted 2.6.32.2 #1
Jan 7 12:39:27 kedge kernel: Call Trace:
Jan 7 12:39:27 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
Jan 7 12:39:27 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
Jan 7 12:39:27 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
Jan 7 12:39:27 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
Jan 7 12:39:27 kedge kernel: Mem-Info:
Jan 7 12:39:27 kedge kernel: DMA per-cpu:
Jan 7 12:39:27 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 7 12:39:27 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 7 12:39:27 kedge kernel: DMA32 per-cpu:
Jan 7 12:39:27 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 158
Jan 7 12:39:27 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 134
Jan 7 12:39:27 kedge kernel: Normal per-cpu:
Jan 7 12:39:27 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 200
Jan 7 12:39:27 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 67
Jan 7 12:39:27 kedge kernel: active_anon:420176 inactive_anon:150891
isolated_anon:0
Jan 7 12:39:27 kedge kernel: active_file:163989 inactive_file:204935
isolated_file:32
Jan 7 12:39:27 kedge kernel: unevictable:0 dirty:74867 writeback:5410
unstable:0
Jan 7 12:39:27 kedge kernel: free:6848 slab_reclaimable:12678
slab_unreclaimable:12867
Jan 7 12:39:27 kedge kernel: mapped:72453 shmem:82598 pagetables:7517
bounce:0
Jan 7 12:39:27 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:12kB inactive_anon:52kB active_file:4kB inactive_file:80kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:4kB
slab_reclaimable:0kB slab_unreclaimable:20kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 7 12:39:27 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 7 12:39:27 kedge kernel: DMA32 free:9712kB min:6084kB low:7604kB
high:9124kB active_anon:1469976kB inactive_anon:370840kB
active_file:445776kB inactive_file:565080kB unevictable:0kB
isolated(anon):0kB isolated(file):128kB present:3062688kB mlocked:0kB
dirty:212584kB writeback:14288kB mapped:165804kB shmem:190264kB
slab_reclaimable:30104kB slab_unreclaimable:34300kB kernel_stack:840kB
pagetables:14756kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:32 all_unreclaimable? no
Jan 7 12:39:27 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 7 12:39:27 kedge kernel: Normal free:1904kB min:1924kB low:2404kB
high:2884kB active_anon:210716kB inactive_anon:232672kB
active_file:210176kB inactive_file:254580kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:969600kB mlocked:0kB
dirty:86784kB writeback:7452kB mapped:124004kB shmem:140124kB
slab_reclaimable:20608kB slab_unreclaimable:17148kB kernel_stack:1792kB
pagetables:15312kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
Jan 7 12:39:27 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 7 12:39:27 kedge kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB 2*64kB
3*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 1*4096kB = 15776kB
Jan 7 12:39:27 kedge kernel: DMA32: 486*4kB 9*8kB 0*16kB 1*32kB 1*64kB
1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 9664kB
Jan 7 12:39:27 kedge kernel: Normal: 442*4kB 11*8kB 3*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1904kB
Jan 7 12:39:27 kedge kernel: 451672 total pagecache pages
Jan 7 12:39:27 kedge kernel: 103 pages in swap cache
Jan 7 12:39:27 kedge kernel: Swap cache stats: add 6976, delete 6873,
find 0/0
Jan 7 12:39:27 kedge kernel: Free swap = 1980212kB
Jan 7 12:39:27 kedge kernel: Total swap = 2008116kB
Jan 7 12:39:27 kedge kernel: 1032192 pages RAM
Jan 7 12:39:27 kedge kernel: 45505 pages reserved
Jan 7 12:39:27 kedge kernel: 692298 pages shared
Jan 7 12:39:27 kedge kernel: 449041 pages non-shared
Jan 7 12:39:27 kedge kernel: Out of memory: kill process 2774
(services.exe) score 51635 or a child
Jan 7 12:39:27 kedge kernel: Killed process 2776 (winedevice.exe)
Jan 7 12:39:28 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 7 12:39:28 kedge kernel: Pid: 1954, comm: X Not tainted 2.6.32.2 #1
Jan 7 12:39:28 kedge kernel: Call Trace:
Jan 7 12:39:28 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
Jan 7 12:39:28 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
Jan 7 12:39:28 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
Jan 7 12:39:28 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
Jan 7 12:39:28 kedge kernel: Mem-Info:
Jan 7 12:39:28 kedge kernel: DMA per-cpu:
Jan 7 12:39:28 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 7 12:39:28 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 7 12:39:28 kedge kernel: DMA32 per-cpu:
Jan 7 12:39:28 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 93
Jan 7 12:39:28 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 142
Jan 7 12:39:28 kedge kernel: Normal per-cpu:
Jan 7 12:39:28 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 22
Jan 7 12:39:28 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 79
Jan 7 12:39:28 kedge kernel: active_anon:420340 inactive_anon:150899
isolated_anon:0
Jan 7 12:39:28 kedge kernel: active_file:163960 inactive_file:204984
isolated_file:32
Jan 7 12:39:28 kedge kernel: unevictable:0 dirty:73435 writeback:5765
unstable:0
Jan 7 12:39:28 kedge kernel: free:6862 slab_reclaimable:12728
slab_unreclaimable:12913
Jan 7 12:39:28 kedge kernel: mapped:72491 shmem:82979 pagetables:7503
bounce:0
Jan 7 12:39:28 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:12kB inactive_anon:52kB active_file:4kB inactive_file:80kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:4kB
slab_reclaimable:0kB slab_unreclaimable:20kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 7 12:39:28 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 7 12:39:28 kedge kernel: DMA32 free:9856kB min:6084kB low:7604kB
high:9124kB active_anon:1470236kB inactive_anon:370840kB
active_file:445788kB inactive_file:565160kB unevictable:0kB
isolated(anon):0kB isolated(file):128kB present:3062688kB mlocked:0kB
dirty:206716kB writeback:14880kB mapped:165724kB shmem:191300kB
slab_reclaimable:30344kB slab_unreclaimable:34264kB kernel_stack:808kB
pagetables:14700kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:320 all_unreclaimable? no
Jan 7 12:39:28 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 7 12:39:28 kedge kernel: Normal free:1816kB min:1924kB low:2404kB
high:2884kB active_anon:211112kB inactive_anon:232704kB
active_file:210048kB inactive_file:254696kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:969600kB mlocked:0kB
dirty:87024kB writeback:8180kB mapped:124236kB shmem:140612kB
slab_reclaimable:20568kB slab_unreclaimable:17368kB kernel_stack:1792kB
pagetables:15312kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:128 all_unreclaimable? no
Jan 7 12:39:28 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 7 12:39:28 kedge kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB 2*64kB
3*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 1*4096kB = 15776kB
Jan 7 12:39:28 kedge kernel: DMA32: 501*4kB 6*8kB 10*16kB 2*32kB 1*64kB
0*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 9764kB
Jan 7 12:39:28 kedge kernel: Normal: 408*4kB 3*8kB 4*16kB 3*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1816kB
Jan 7 12:39:28 kedge kernel: 452076 total pagecache pages
Jan 7 12:39:28 kedge kernel: 110 pages in swap cache
Jan 7 12:39:28 kedge kernel: Swap cache stats: add 6984, delete 6874,
find 0/1
Jan 7 12:39:28 kedge kernel: Free swap = 1980216kB
Jan 7 12:39:28 kedge kernel: Total swap = 2008116kB
Jan 7 12:39:28 kedge kernel: 1032192 pages RAM
Jan 7 12:39:28 kedge kernel: 45505 pages reserved
Jan 7 12:39:28 kedge kernel: 693720 pages shared
Jan 7 12:39:28 kedge kernel: 447481 pages non-shared
Jan 7 12:39:28 kedge kernel: Out of memory: kill process 2284 (kdeinit4)
score 40807 or a child
Jan 7 12:39:28 kedge kernel: Killed process 2285 (klauncher)
Jan 7 12:39:37 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 7 12:39:37 kedge kernel: Pid: 1954, comm: X Not tainted 2.6.32.2 #1
Jan 7 12:39:37 kedge kernel: Call Trace:
Jan 7 12:39:37 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
Jan 7 12:39:37 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
Jan 7 12:39:37 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
Jan 7 12:39:37 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
Jan 7 12:39:37 kedge kernel: Mem-Info:
Jan 7 12:39:37 kedge kernel: DMA per-cpu:
Jan 7 12:39:37 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 7 12:39:37 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 7 12:39:37 kedge kernel: DMA32 per-cpu:
Jan 7 12:39:37 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 148
Jan 7 12:39:37 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 185
Jan 7 12:39:37 kedge kernel: Normal per-cpu:
Jan 7 12:39:37 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 75
Jan 7 12:39:37 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 82
Jan 7 12:39:37 kedge kernel: active_anon:420619 inactive_anon:150667
isolated_anon:0
Jan 7 12:39:37 kedge kernel: active_file:163905 inactive_file:205729
isolated_file:32
Jan 7 12:39:37 kedge kernel: unevictable:0 dirty:81537 writeback:3643
unstable:0
Jan 7 12:39:37 kedge kernel: free:6887 slab_reclaimable:12055
slab_unreclaimable:12667
Jan 7 12:39:37 kedge kernel: mapped:72567 shmem:83099 pagetables:7502
bounce:0
Jan 7 12:39:37 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:12kB inactive_anon:52kB active_file:4kB inactive_file:80kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:4kB
slab_reclaimable:0kB slab_unreclaimable:20kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 7 12:39:37 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 7 12:39:37 kedge kernel: DMA32 free:9856kB min:6084kB low:7604kB
high:9124kB active_anon:1469840kB inactive_anon:370824kB
active_file:445864kB inactive_file:567788kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:3062688kB mlocked:0kB
dirty:227772kB writeback:10748kB mapped:165964kB shmem:190888kB
slab_reclaimable:28496kB slab_unreclaimable:33328kB kernel_stack:808kB
pagetables:14700kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:192 all_unreclaimable? no
Jan 7 12:39:37 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 7 12:39:37 kedge kernel: Normal free:1916kB min:1924kB low:2404kB
high:2884kB active_anon:212624kB inactive_anon:231792kB
active_file:209752kB inactive_file:255048kB unevictable:0kB
isolated(anon):0kB isolated(file):128kB present:969600kB mlocked:0kB
dirty:98376kB writeback:3824kB mapped:124300kB shmem:141504kB
slab_reclaimable:19724kB slab_unreclaimable:17320kB kernel_stack:1792kB
pagetables:15308kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
Jan 7 12:39:37 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 7 12:39:37 kedge kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB 2*64kB
3*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 1*4096kB = 15776kB
Jan 7 12:39:37 kedge kernel: DMA32: 504*4kB 0*8kB 10*16kB 8*32kB 4*64kB
0*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 9856kB
Jan 7 12:39:37 kedge kernel: Normal: 479*4kB 0*8kB 1*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1932kB
Jan 7 12:39:37 kedge kernel: 452912 total pagecache pages
Jan 7 12:39:37 kedge kernel: 110 pages in swap cache
Jan 7 12:39:37 kedge kernel: Swap cache stats: add 6984, delete 6874,
find 0/1
Jan 7 12:39:37 kedge kernel: Free swap = 1980216kB
Jan 7 12:39:37 kedge kernel: Total swap = 2008116kB
Jan 7 12:39:37 kedge kernel: 1032192 pages RAM
Jan 7 12:39:37 kedge kernel: 45505 pages reserved
Jan 7 12:39:37 kedge kernel: 673963 pages shared
Jan 7 12:39:37 kedge kernel: 466837 pages non-shared
Jan 7 12:39:37 kedge kernel: Out of memory: kill process 2284 (kdeinit4)
score 40802 or a child
Jan 7 12:39:37 kedge kernel: Killed process 2315 (ksmserver)
Jan 7 14:55:00 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 7 14:55:00 kedge kernel: Pid: 1949, comm: X Not tainted 2.6.32.2 #1
Jan 7 14:55:00 kedge kernel: Call Trace:
Jan 7 14:55:00 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
Jan 7 14:55:00 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
Jan 7 14:55:00 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
Jan 7 14:55:00 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
Jan 7 14:55:00 kedge kernel: Mem-Info:
Jan 7 14:55:00 kedge kernel: DMA per-cpu:
Jan 7 14:55:00 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 7 14:55:00 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 7 14:55:00 kedge kernel: DMA32 per-cpu:
Jan 7 14:55:00 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 124
Jan 7 14:55:00 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 64
Jan 7 14:55:00 kedge kernel: Normal per-cpu:
Jan 7 14:55:00 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 60
Jan 7 14:55:00 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 124
Jan 7 14:55:00 kedge kernel: active_anon:428715 inactive_anon:170886
isolated_anon:0
Jan 7 14:55:00 kedge kernel: active_file:83424 inactive_file:259387
isolated_file:64
Jan 7 14:55:00 kedge kernel: unevictable:52 dirty:134577 writeback:3053
unstable:0
Jan 7 14:55:00 kedge kernel: free:6862 slab_reclaimable:14067
slab_unreclaimable:11265
Jan 7 14:55:00 kedge kernel: mapped:48961 shmem:78608 pagetables:5783
bounce:0
Jan 7 14:55:00 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:32kB inactive_anon:128kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 7 14:55:00 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 7 14:55:00 kedge kernel: DMA32 free:9760kB min:6084kB low:7604kB
high:9124kB active_anon:1415932kB inactive_anon:363400kB
active_file:206448kB inactive_file:873788kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:3062688kB mlocked:0kB
dirty:457220kB writeback:6548kB mapped:87700kB shmem:173796kB
slab_reclaimable:37724kB slab_unreclaimable:27968kB kernel_stack:408kB
pagetables:8040kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:192 all_unreclaimable? no
Jan 7 14:55:00 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 7 14:55:00 kedge kernel: Normal free:1912kB min:1924kB low:2404kB
high:2884kB active_anon:298896kB inactive_anon:320016kB
active_file:127248kB inactive_file:163760kB unevictable:208kB
isolated(anon):0kB isolated(file):256kB present:969600kB mlocked:208kB
dirty:81088kB writeback:5664kB mapped:108144kB shmem:140636kB
slab_reclaimable:18544kB slab_unreclaimable:17084kB kernel_stack:1848kB
pagetables:15092kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:128 all_unreclaimable? no
Jan 7 14:55:00 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 7 14:55:00 kedge kernel: DMA: 0*4kB 2*8kB 1*16kB 2*32kB 1*64kB
2*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15776kB
Jan 7 14:55:00 kedge kernel: DMA32: 292*4kB 154*8kB 29*16kB 4*32kB 4*64kB
3*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 1*4096kB = 9776kB
Jan 7 14:55:00 kedge kernel: Normal: 322*4kB 70*8kB 4*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1912kB
Jan 7 14:55:00 kedge kernel: 421622 total pagecache pages
Jan 7 14:55:00 kedge kernel: 77 pages in swap cache
Jan 7 14:55:00 kedge kernel: Swap cache stats: add 332, delete 255, find
25/33
Jan 7 14:55:00 kedge kernel: Free swap = 2007408kB
Jan 7 14:55:00 kedge kernel: Total swap = 2008116kB
Jan 7 14:55:00 kedge kernel: 1032192 pages RAM
Jan 7 14:55:00 kedge kernel: 45505 pages reserved
Jan 7 14:55:00 kedge kernel: 698655 pages shared
Jan 7 14:55:00 kedge kernel: 395124 pages non-shared
Jan 7 14:55:00 kedge kernel: Out of memory: kill process 2292 (kdeinit4)
score 31321 or a child
Jan 7 14:55:00 kedge kernel: Killed process 2293 (klauncher)
Jan 8 11:47:13 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 8 11:47:13 kedge kernel: Pid: 1947, comm: X Not tainted 2.6.32.2 #1
Jan 8 11:47:13 kedge kernel: Call Trace:
Jan 8 11:47:13 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
Jan 8 11:47:13 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
Jan 8 11:47:13 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
Jan 8 11:47:13 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
Jan 8 11:47:13 kedge kernel: Mem-Info:
Jan 8 11:47:13 kedge kernel: DMA per-cpu:
Jan 8 11:47:13 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 8 11:47:13 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 8 11:47:13 kedge kernel: DMA32 per-cpu:
Jan 8 11:47:13 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 176
Jan 8 11:47:13 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 37
Jan 8 11:47:13 kedge kernel: Normal per-cpu:
Jan 8 11:47:13 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 162
Jan 8 11:47:13 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 184
Jan 8 11:47:13 kedge kernel: active_anon:477285 inactive_anon:203470
isolated_anon:224
Jan 8 11:47:13 kedge kernel: active_file:2741 inactive_file:2702
isolated_file:1
Jan 8 11:47:13 kedge kernel: unevictable:262400 dirty:3 writeback:7734
unstable:0
Jan 8 11:47:13 kedge kernel: free:6860 slab_reclaimable:4386
slab_unreclaimable:12827
Jan 8 11:47:13 kedge kernel: mapped:15209 shmem:45527 pagetables:7496
bounce:0
Jan 8 11:47:13 kedge kernel: DMA free:15764kB min:28kB low:32kB high:40kB
active_anon:32kB inactive_anon:140kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 8 11:47:13 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 8 11:47:13 kedge kernel: DMA32 free:9752kB min:6084kB low:7604kB
high:9124kB active_anon:1460924kB inactive_anon:365512kB
active_file:4012kB inactive_file:4152kB unevictable:1047324kB
isolated(anon):508kB isolated(file):4kB present:3062688kB
mlocked:1047324kB dirty:8kB writeback:11656kB mapped:50396kB
shmem:112632kB slab_reclaimable:7736kB slab_unreclaimable:30688kB
kernel_stack:608kB pagetables:12120kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:1352 all_unreclaimable? no
Jan 8 11:47:13 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 8 11:47:13 kedge kernel: Normal free:1924kB min:1924kB low:2404kB
high:2884kB active_anon:448184kB inactive_anon:448328kB active_file:6952kB
inactive_file:6656kB unevictable:2276kB isolated(anon):260kB
isolated(file):0kB present:969600kB mlocked:2276kB dirty:4kB
writeback:19280kB mapped:10440kB shmem:69476kB slab_reclaimable:9808kB
slab_unreclaimable:20612kB kernel_stack:1744kB pagetables:17864kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:96
all_unreclaimable? no
Jan 8 11:47:13 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 8 11:47:13 kedge kernel: DMA: 1*4kB 2*8kB 2*16kB 1*32kB 1*64kB
2*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15764kB
Jan 8 11:47:13 kedge kernel: DMA32: 144*4kB 95*8kB 14*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 2*4096kB = 9752kB
Jan 8 11:47:14 kedge kernel: Normal: 465*4kB 8*8kB 0*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1924kB
Jan 8 11:47:14 kedge kernel: 63561 total pagecache pages
Jan 8 11:47:14 kedge kernel: 12649 pages in swap cache
Jan 8 11:47:14 kedge kernel: Swap cache stats: add 562887, delete 550238,
find 1428/2715
Jan 8 11:47:14 kedge kernel: Free swap = 848784kB
Jan 8 11:47:14 kedge kernel: Total swap = 2008116kB
Jan 8 11:47:14 kedge kernel: 1032192 pages RAM
Jan 8 11:47:14 kedge kernel: 45505 pages reserved
Jan 8 11:47:14 kedge kernel: 307214 pages shared
Jan 8 11:47:14 kedge kernel: 688958 pages non-shared
Jan 8 11:47:14 kedge kernel: Out of memory: kill process 2277 (kdeinit4)
score 68719 or a child
Jan 8 11:47:14 kedge kernel: Killed process 2278 (klauncher)
Jan 8 11:47:51 kedge kernel: VirtualBox[2607]: segfault at 7f067e56783c
ip 00007f0695e16a00 sp 00007fffcec60018 error 4 in
libc-2.11.so[7f0695d96000+150000]
Jan 12 10:39:57 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 12 10:39:57 kedge kernel: Pid: 1897, comm: X Not tainted 2.6.32.3 #1
Jan 12 10:39:57 kedge kernel: Call Trace:
Jan 12 10:39:57 kedge kernel: [<ffffffff8107b2dd>] ? 0xffffffff8107b2dd
Jan 12 10:39:57 kedge kernel: [<ffffffff8107b5c3>] ? 0xffffffff8107b5c3
Jan 12 10:39:57 kedge kernel: [<ffffffff8107b737>] ? 0xffffffff8107b737
Jan 12 10:39:57 kedge kernel: [<ffffffff8155eb1f>] ? 0xffffffff8155eb1f
Jan 12 10:39:57 kedge kernel: Mem-Info:
Jan 12 10:39:57 kedge kernel: DMA per-cpu:
Jan 12 10:39:57 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 12 10:39:57 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 12 10:39:57 kedge kernel: DMA32 per-cpu:
Jan 12 10:39:57 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 115
Jan 12 10:39:57 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 105
Jan 12 10:39:57 kedge kernel: Normal per-cpu:
Jan 12 10:39:57 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 76
Jan 12 10:39:57 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 157
Jan 12 10:39:57 kedge kernel: active_anon:370078 inactive_anon:134712
isolated_anon:0
Jan 12 10:39:57 kedge kernel: active_file:207094 inactive_file:231726
isolated_file:33
Jan 12 10:39:57 kedge kernel: unevictable:0 dirty:110374 writeback:2787
unstable:0
Jan 12 10:39:57 kedge kernel: free:6854 slab_reclaimable:14273
slab_unreclaimable:10152
Jan 12 10:39:57 kedge kernel: mapped:44713 shmem:60225 pagetables:5405
bounce:0
Jan 12 10:39:57 kedge kernel: DMA free:15760kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:96kB inactive_file:68kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:12kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 12 10:39:57 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 12 10:39:57 kedge kernel: DMA32 free:9852kB min:6084kB low:7604kB
high:9124kB active_anon:1302612kB inactive_anon:338676kB
active_file:581560kB inactive_file:644216kB unevictable:0kB
isolated(anon):0kB isolated(file):132kB present:3062688kB mlocked:0kB
dirty:361808kB writeback:8408kB mapped:73948kB shmem:127740kB
slab_reclaimable:33636kB slab_unreclaimable:23436kB kernel_stack:696kB
pagetables:7780kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:128 all_unreclaimable? no
Jan 12 10:39:57 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 12 10:39:57 kedge kernel: Normal free:1804kB min:1924kB low:2404kB
high:2884kB active_anon:177700kB inactive_anon:200172kB
active_file:246720kB inactive_file:282620kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:969600kB mlocked:0kB
dirty:79688kB writeback:2740kB mapped:104904kB shmem:113160kB
slab_reclaimable:23444kB slab_unreclaimable:17164kB kernel_stack:1736kB
pagetables:13840kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
Jan 12 10:39:57 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 12 10:39:57 kedge kernel: DMA: 2*4kB 1*8kB 2*16kB 3*32kB 2*64kB
3*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 1*4096kB = 15760kB
Jan 12 10:39:57 kedge kernel: DMA32: 119*4kB 4*8kB 74*16kB 31*32kB 14*64kB
1*128kB 2*256kB 1*512kB 1*1024kB 0*2048kB 1*4096kB = 9852kB
Jan 12 10:39:57 kedge kernel: Normal: 459*4kB 0*8kB 0*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1836kB
Jan 12 10:39:57 kedge kernel: 500016 total pagecache pages
Jan 12 10:39:57 kedge kernel: 874 pages in swap cache
Jan 12 10:39:57 kedge kernel: Swap cache stats: add 7068, delete 6194,
find 365/500
Jan 12 10:39:57 kedge kernel: Free swap = 1985148kB
Jan 12 10:39:57 kedge kernel: Total swap = 2008116kB
Jan 12 10:39:57 kedge kernel: 1032192 pages RAM
Jan 12 10:39:57 kedge kernel: 45537 pages reserved
Jan 12 10:39:57 kedge kernel: 717169 pages shared
Jan 12 10:39:57 kedge kernel: 368611 pages non-shared
Jan 12 10:39:57 kedge kernel: Out of memory: kill process 2245 (kdeinit4)
score 6562989 or a child
Jan 12 10:39:57 kedge kernel: Killed process 2246 (klauncher)
Jan 13 14:56:29 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 13 14:56:29 kedge kernel: Pid: 1896, comm: X Not tainted 2.6.32.3 #1
Jan 13 14:56:29 kedge kernel: Call Trace:
Jan 13 14:56:29 kedge kernel: [<ffffffff8107b2dd>] ? 0xffffffff8107b2dd
Jan 13 14:56:29 kedge kernel: [<ffffffff8107b5c3>] ? 0xffffffff8107b5c3
Jan 13 14:56:29 kedge kernel: [<ffffffff8107b737>] ? 0xffffffff8107b737
Jan 13 14:56:29 kedge kernel: [<ffffffff8155eb1f>] ? 0xffffffff8155eb1f
Jan 13 14:56:29 kedge kernel: Mem-Info:
Jan 13 14:56:29 kedge kernel: DMA per-cpu:
Jan 13 14:56:29 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 13 14:56:30 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 13 14:56:30 kedge kernel: DMA32 per-cpu:
Jan 13 14:56:30 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 102
Jan 13 14:56:30 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 164
Jan 13 14:56:30 kedge kernel: Normal per-cpu:
Jan 13 14:56:30 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 105
Jan 13 14:56:30 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 176
Jan 13 14:56:30 kedge kernel: active_anon:632132 inactive_anon:230704
isolated_anon:32
Jan 13 14:56:30 kedge kernel: active_file:39830 inactive_file:38082
isolated_file:34
Jan 13 14:56:30 kedge kernel: unevictable:16 dirty:337 writeback:337
unstable:0
Jan 13 14:56:30 kedge kernel: free:6865 slab_reclaimable:8416
slab_unreclaimable:16167
Jan 13 14:56:30 kedge kernel: mapped:43419 shmem:84996 pagetables:6944
bounce:0
Jan 13 14:56:30 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:12kB inactive_file:144kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:4kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 13 14:56:30 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 13 14:56:30 kedge kernel: DMA32 free:9768kB min:6084kB low:7604kB
high:9124kB active_anon:2141204kB inactive_anon:535376kB
active_file:93848kB inactive_file:90092kB unevictable:64kB
isolated(anon):0kB isolated(file):0kB present:3062688kB mlocked:64kB
dirty:88kB writeback:444kB mapped:107488kB shmem:187252kB
slab_reclaimable:18856kB slab_unreclaimable:39592kB kernel_stack:1360kB
pagetables:11092kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:0 all_unreclaimable? no
Jan 13 14:56:30 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 13 14:56:30 kedge kernel: Normal free:1916kB min:1924kB low:2404kB
high:2884kB active_anon:387324kB inactive_anon:387440kB
active_file:65460kB inactive_file:62092kB unevictable:0kB
isolated(anon):128kB isolated(file):136kB present:969600kB mlocked:0kB
dirty:1260kB writeback:904kB mapped:66188kB shmem:152732kB
slab_reclaimable:14804kB slab_unreclaimable:25068kB kernel_stack:2032kB
pagetables:16684kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:226 all_unreclaimable? no
Jan 13 14:56:30 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 13 14:56:30 kedge kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB 2*64kB
3*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 1*4096kB = 15776kB
Jan 13 14:56:30 kedge kernel: DMA32: 50*4kB 363*8kB 25*16kB 6*32kB 1*64kB
1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 1*4096kB = 9776kB
Jan 13 14:56:30 kedge kernel: Normal: 337*4kB 53*8kB 9*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1916kB
Jan 13 14:56:30 kedge kernel: 168802 total pagecache pages
Jan 13 14:56:30 kedge kernel: 5824 pages in swap cache
Jan 13 14:56:30 kedge kernel: Swap cache stats: add 35239, delete 29415,
find 3247/3937
Jan 13 14:56:30 kedge kernel: Free swap = 6084124kB
Jan 13 14:56:30 kedge kernel: Total swap = 6202412kB
Jan 13 14:56:30 kedge kernel: 1032192 pages RAM
Jan 13 14:56:30 kedge kernel: 45537 pages reserved
Jan 13 14:56:30 kedge kernel: 454756 pages shared
Jan 13 14:56:30 kedge kernel: 627506 pages non-shared
Jan 13 14:56:30 kedge kernel: Out of memory: kill process 3607 (eclipse)
score 11190403 or a child
Jan 13 14:56:30 kedge kernel: Killed process 3817 (java)
Jan 14 12:22:32 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 14 12:22:32 kedge kernel: Pid: 1877, comm: X Not tainted 2.6.32.3 #1
Jan 14 12:22:32 kedge kernel: Call Trace:
Jan 14 12:22:32 kedge kernel: [<ffffffff8107b2dd>] ? 0xffffffff8107b2dd
Jan 14 12:22:32 kedge kernel: [<ffffffff8107b5c3>] ? 0xffffffff8107b5c3
Jan 14 12:22:32 kedge kernel: [<ffffffff8107b737>] ? 0xffffffff8107b737
Jan 14 12:22:32 kedge kernel: [<ffffffff8155eb1f>] ? 0xffffffff8155eb1f
Jan 14 12:22:32 kedge kernel: Mem-Info:
Jan 14 12:22:32 kedge kernel: DMA per-cpu:
Jan 14 12:22:32 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 14 12:22:32 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 14 12:22:32 kedge kernel: DMA32 per-cpu:
Jan 14 12:22:32 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 147
Jan 14 12:22:32 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 125
Jan 14 12:22:32 kedge kernel: Normal per-cpu:
Jan 14 12:22:32 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 58
Jan 14 12:22:32 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 117
Jan 14 12:22:32 kedge kernel: active_anon:159855 inactive_anon:145129
isolated_anon:0
Jan 14 12:22:32 kedge kernel: active_file:166370 inactive_file:477851
isolated_file:35
Jan 14 12:22:32 kedge kernel: unevictable:1 dirty:165274 writeback:2333
unstable:0
Jan 14 12:22:32 kedge kernel: free:6860 slab_reclaimable:15652
slab_unreclaimable:11286
Jan 14 12:22:32 kedge kernel: mapped:47579 shmem:63280 pagetables:5848
bounce:0
Jan 14 12:22:32 kedge kernel: DMA free:15760kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:176kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 14 12:22:32 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 14 12:22:32 kedge kernel: DMA32 free:9852kB min:6084kB low:7604kB
high:9124kB active_anon:422628kB inactive_anon:354268kB
active_file:449432kB inactive_file:1660944kB unevictable:0kB
isolated(anon):0kB isolated(file):140kB present:3062688kB mlocked:0kB
dirty:575624kB writeback:8540kB mapped:59012kB shmem:141264kB
slab_reclaimable:41560kB slab_unreclaimable:27284kB kernel_stack:832kB
pagetables:10048kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:320 all_unreclaimable? no
Jan 14 12:22:32 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 14 12:22:32 kedge kernel: Normal free:1828kB min:1924kB low:2404kB
high:2884kB active_anon:216792kB inactive_anon:226248kB
active_file:216048kB inactive_file:250284kB unevictable:4kB
isolated(anon):0kB isolated(file):0kB present:969600kB mlocked:4kB
dirty:85472kB writeback:792kB mapped:131304kB shmem:111856kB
slab_reclaimable:21048kB slab_unreclaimable:17852kB kernel_stack:1816kB
pagetables:13344kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:96 all_unreclaimable? no
Jan 14 12:22:32 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 14 12:22:32 kedge kernel: DMA: 0*4kB 2*8kB 2*16kB 1*32kB 1*64kB
2*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15760kB
Jan 14 12:22:32 kedge kernel: DMA32: 467*4kB 0*8kB 4*16kB 4*32kB 2*64kB
0*128kB 2*256kB 0*512kB 1*1024kB 1*2048kB 1*4096kB = 9868kB
Jan 14 12:22:32 kedge kernel: Normal: 457*4kB 0*8kB 0*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1828kB
Jan 14 12:22:32 kedge kernel: 707519 total pagecache pages
Jan 14 12:22:32 kedge kernel: 0 pages in swap cache
Jan 14 12:22:32 kedge kernel: Swap cache stats: add 25, delete 25, find 0/0
Jan 14 12:22:32 kedge kernel: Free swap = 2008016kB
Jan 14 12:22:32 kedge kernel: Total swap = 2008116kB
Jan 14 12:22:32 kedge kernel: 1032192 pages RAM
Jan 14 12:22:32 kedge kernel: 36884 pages reserved
Jan 14 12:22:32 kedge kernel: 511141 pages shared
Jan 14 12:22:32 kedge kernel: 607236 pages non-shared
Jan 14 12:22:32 kedge kernel: Out of memory: kill process 2223 (kdeinit4)
score 6720518 or a child
Jan 14 12:22:32 kedge kernel: Killed process 2224 (klauncher)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-14 13:15 OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
@ 2010-01-23 0:40 ` David Rientjes
2010-01-25 22:12 ` Roman Jarosz
2010-01-25 1:48 ` KOSAKI Motohiro
1 sibling, 1 reply; 52+ messages in thread
From: David Rientjes @ 2010-01-23 0:40 UTC (permalink / raw)
To: Roman Jarosz; +Cc: linux-kernel, KOSAKI Motohiro, Andrew Morton
On Thu, 14 Jan 2010, Roman Jarosz wrote:
> Hi,
>
> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer kills
> when I do hard disk intensive tasks (mainly in VirtualBox which is running
> Windows XP) and IMHO it kills processes even if I have a lot of free memory.
>
> Is this a known bug? I have self compiled kernel so I can try patches.
>
> Regards
> Roman Jarosz
>
> PS. Please CC me.
>
> Jan 7 12:39:27 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
> oom_adj=0
The gfp_mask of 0x0 and order of 0 indicate these are triggered by
pagefaults that end up returning VM_FAULT_OOM. Prior to 2.6.29, the
current task (X in all cases from your log) would have been SIGKILLed; we
now call the oom killer instead of kill a memory hogging task so that the
fault is retried with more success. If you've upgraded from a 2.6.29 or
later kernel and are only now experiencing these errors, it may indicate a
regression in VM that we need to investigate (and, if so, you may want to
try merging f50de2d38 from 2.6.33 to see if it helps keep more ZONE_NORMAL
memory available so that such drastic measures aren't necessary).
> Jan 7 12:39:27 kedge kernel: Pid: 1954, comm: X Not tainted 2.6.32.2 #1
> Jan 7 12:39:27 kedge kernel: Call Trace:
> Jan 7 12:39:27 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
> Jan 7 12:39:27 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
> Jan 7 12:39:27 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
> Jan 7 12:39:27 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
Can you find out what these symbols are?
> Jan 7 12:39:27 kedge kernel: Mem-Info:
> Jan 7 12:39:27 kedge kernel: DMA per-cpu:
> Jan 7 12:39:27 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
> Jan 7 12:39:27 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
> Jan 7 12:39:27 kedge kernel: DMA32 per-cpu:
> Jan 7 12:39:27 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 158
> Jan 7 12:39:27 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 134
> Jan 7 12:39:27 kedge kernel: Normal per-cpu:
> Jan 7 12:39:27 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 200
> Jan 7 12:39:27 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 67
> Jan 7 12:39:27 kedge kernel: active_anon:420176 inactive_anon:150891
> isolated_anon:0
> Jan 7 12:39:27 kedge kernel: active_file:163989 inactive_file:204935
> isolated_file:32
> Jan 7 12:39:27 kedge kernel: unevictable:0 dirty:74867 writeback:5410
> unstable:0
> Jan 7 12:39:27 kedge kernel: free:6848 slab_reclaimable:12678
> slab_unreclaimable:12867
> Jan 7 12:39:27 kedge kernel: mapped:72453 shmem:82598 pagetables:7517
> bounce:0
> Jan 7 12:39:27 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
> active_anon:12kB inactive_anon:52kB active_file:4kB inactive_file:80kB
> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
> mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:4kB slab_reclaimable:0kB
> slab_unreclaimable:20kB kernel_stack:0kB pagetables:0kB unstable:0kB
> bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> Jan 7 12:39:27 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Although this appears that there is an abundance of memory available, its
inaccessible because of the lowmem_reserve: 3937 pages are reserved for
these types of allocations in ZONE_DMA, so assuming 4K page sizes:
15776kB (free) - (4kB * 3937 lowmem_reserve) <= 28kB (min).
> Jan 7 12:39:27 kedge kernel: DMA32 free:9712kB min:6084kB low:7604kB
> high:9124kB active_anon:1469976kB inactive_anon:370840kB active_file:445776kB
> inactive_file:565080kB unevictable:0kB isolated(anon):0kB isolated(file):128kB
> present:3062688kB mlocked:0kB dirty:212584kB writeback:14288kB mapped:165804kB
> shmem:190264kB slab_reclaimable:30104kB slab_unreclaimable:34300kB
> kernel_stack:840kB pagetables:14756kB unstable:0kB bounce:0kB
> writeback_tmp:0kB pages_scanned:32 all_unreclaimable? no
> Jan 7 12:39:27 kedge kernel: lowmem_reserve[]: 0 0 946 946
Same:
9712kB - (4kB * 946) <= 6084kB.
> Jan 7 12:39:27 kedge kernel: Normal free:1904kB min:1924kB low:2404kB
> high:2884kB active_anon:210716kB inactive_anon:232672kB active_file:210176kB
> inactive_file:254580kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
> present:969600kB mlocked:0kB dirty:86784kB writeback:7452kB mapped:124004kB
> shmem:140124kB slab_reclaimable:20608kB slab_unreclaimable:17148kB
> kernel_stack:1792kB pagetables:15312kB unstable:0kB bounce:0kB
> writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
This shows ZONE_NORMAL is depleted, but we'll need to know where the
regression started since 2.6.29 to find out why indirect reclaim isn't
keeping a sufficient amount free anymore for your I/O bound task.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-14 13:15 OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
2010-01-23 0:40 ` David Rientjes
@ 2010-01-25 1:48 ` KOSAKI Motohiro
2010-01-25 20:47 ` Roman Jarosz
1 sibling, 1 reply; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-25 1:48 UTC (permalink / raw)
To: Roman Jarosz; +Cc: kosaki.motohiro, lkml
> Hi,
>
> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
> kills when I do hard disk intensive tasks (mainly in VirtualBox which is
> running Windows XP) and IMHO it kills processes even if I have a lot of
> free memory.
>
> Is this a known bug? I have self compiled kernel so I can try patches.
Can you please post your .config?
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-25 1:48 ` KOSAKI Motohiro
@ 2010-01-25 20:47 ` Roman Jarosz
2010-01-26 5:19 ` KOSAKI Motohiro
0 siblings, 1 reply; 52+ messages in thread
From: Roman Jarosz @ 2010-01-25 20:47 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: lkml
On Mon, 25 Jan 2010 02:48:08 +0100, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> Hi,
>>
>> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
>> kills when I do hard disk intensive tasks (mainly in VirtualBox which is
>> running Windows XP) and IMHO it kills processes even if I have a lot of
>> free memory.
>>
>> Is this a known bug? I have self compiled kernel so I can try patches.
>
> Can you please post your .config?
>
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.32.3
# Fri Jan 8 16:01:41 2010
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_TREE_PREEMPT_RCU is not set
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=64
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
# CONFIG_UID16 is not set
# CONFIG_SYSCTL_SYSCALL is not set
# CONFIG_KALLSYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_EVENTS=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
# CONFIG_PERF_COUNTERS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_SLUB_DEBUG is not set
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
#
# GCOV-based kernel profiling
#
CONFIG_SLOW_WORK=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_FREEZER=y
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_SPARSE_IRQ is not set
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_MATOM is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_P6_NOP=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
# CONFIG_PROCESSOR_SELECT is not set
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_X86_CPU_DEBUG is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
# CONFIG_DIRECT_GBPAGES is not set
# CONFIG_NUMA is not set
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
# CONFIG_PM_RUNTIME is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
# CONFIG_ACPI_POWER_METER is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_SFI is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set
#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
# CONFIG_INTR_REMAP is not set
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
# CONFIG_PCIEASPM is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
# CONFIG_HAVE_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y
CONFIG_COMPAT_NETLINK_MESSAGES=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
CONFIG_NF_CONNTRACK=y
# CONFIG_NF_CT_ACCT is not set
# CONFIG_NF_CONNTRACK_MARK is not set
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=y
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=y
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_LED is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_HL is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_VS is not set
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_FTP=m
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=y
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=y
# CONFIG_IP6_NF_MATCH_AH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_HL is not set
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_MH is not set
CONFIG_IP6_NF_MATCH_RT=y
# CONFIG_IP6_NF_TARGET_HL is not set
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=m
# CONFIG_IP6_NF_MANGLE is not set
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP6_NF_SECURITY is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=y
# CONFIG_BT_RFCOMM_TTY is not set
CONFIG_BT_BNEP=y
# CONFIG_BT_BNEP_MC_FILTER is not set
# CONFIG_BT_BNEP_PROTO_FILTER is not set
CONFIG_BT_HIDP=y
#
# Bluetooth device drivers
#
# CONFIG_BT_HCIBTUSB is not set
# CONFIG_BT_HCIBTSDIO is not set
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_BT_MRVL is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_DEFAULT_PS_VALUE=1
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m
CONFIG_MAC80211_RC_PID=y
# CONFIG_MAC80211_RC_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_SCH is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# You can enable one or both FireWire driver stacks.
#
#
# See the help texts for more information.
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m
# CONFIG_IEEE1394_OHCI1394 is not set
# CONFIG_IEEE1394_PCILYNX is not set
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_RAWIO is not set
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_ENC28J60 is not set
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
CONFIG_E1000E=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
CONFIG_CHELSIO_T3_DEPENDS=y
# CONFIG_CHELSIO_T3 is not set
# CONFIG_ENIC is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI is not set
# CONFIG_BNX2X is not set
# CONFIG_QLGE is not set
# CONFIG_SFC is not set
# CONFIG_BE2NET is not set
# CONFIG_TR is not set
CONFIG_WLAN=y
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH_COMMON is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set
# CONFIG_IWLWIFI_DEBUG is not set
CONFIG_IWLAGN=m
CONFIG_IWL4965=y
# CONFIG_IWL5000 is not set
# CONFIG_IWL3945 is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
# CONFIG_WL12XX is not set
# CONFIG_IWM is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=y
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_ALPS is not set
# CONFIG_MOUSE_PS2_LOGIPS2PP is not set
CONFIG_MOUSE_PS2_SYNAPTICS=y
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m
# CONFIG_INPUT_WINBOND_CIR is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
CONFIG_FIX_EARLYCON_MEM=y
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set
#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
CONFIG_SPI=y
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
CONFIG_SPI_BITBANG=y
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
#
# PPS support
#
# CONFIG_PPS is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_CORETEMP=y
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
#
# ACPI drivers
#
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_LIS3LV02D is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13783 is not set
# CONFIG_AB3100_CORE is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_VGA_ARB is not set
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
# CONFIG_LCD_PLATFORM is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=256
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
CONFIG_SOUND=m
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_SEQUENCER_OSS is not set
# CONFIG_SND_HRTIMER is not set
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_INPUT_JACK is not set
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_SPI=y
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y
#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
# CONFIG_HID_DRAGONRISE is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_KYE is not set
CONFIG_HID_GYRATION=y
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
CONFIG_HID_LOGITECH=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
# CONFIG_HID_NTRIG is not set
CONFIG_HID_PANTHERLORD=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_ZEROPLUS is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB port drivers
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_EZUSB is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MOTOROLA is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
CONFIG_USB_SERIAL_PL2303=m
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_SYMBOL is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_DEBUG is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set
#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_WBSD is not set
# CONFIG_MMC_AT91 is not set
# CONFIG_MMC_ATMELMCI is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set
#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
# CONFIG_MSPRO_BLOCK is not set
#
# MemoryStick Host Controller Drivers
#
# CONFIG_MEMSTICK_TIFM_MS is not set
# CONFIG_MEMSTICK_JMICRON_38X is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_BD2802 is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
#
# TI VLYNQ
#
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
CONFIG_THINKPAD_ACPI=m
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
# CONFIG_THINKPAD_ACPI_VIDEO is not set
# CONFIG_THINKPAD_ACPI_HOTKEY_POLL is not set
# CONFIG_INTEL_MENLOW is not set
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_ACPI_TOSHIBA is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
# CONFIG_EXT4_FS_SECURITY is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
CONFIG_JBD2=y
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
# CONFIG_REISERFS_FS_SECURITY is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set
CONFIG_GENERIC_ACL=y
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
CONFIG_CODA_FS=m
# CONFIG_AFS_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=y
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
# CONFIG_FRAME_POINTER is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_LATENCYTOP is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_X86_VERBOSE_BOOTUP is not set
# CONFIG_EARLY_PRINTK is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_OPTIMIZE_INLINING is not set
#
# Security options
#
# CONFIG_KEYS is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_SECURITY_ROOTPLUG is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=y
# CONFIG_CRYPTO_LRW is not set
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_GHASH is not set
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_WP512=y
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
# CONFIG_CRYPTO_AES_NI_INTEL is not set
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_BLOWFISH=y
# CONFIG_CRYPTO_CAMELLIA is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=y
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_TEA=y
# CONFIG_CRYPTO_TWOFISH is not set
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_TWOFISH_X86_64=y
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-23 0:40 ` David Rientjes
@ 2010-01-25 22:12 ` Roman Jarosz
0 siblings, 0 replies; 52+ messages in thread
From: Roman Jarosz @ 2010-01-25 22:12 UTC (permalink / raw)
To: David Rientjes; +Cc: linux-kernel, KOSAKI Motohiro, Andrew Morton
On Sat, 23 Jan 2010 01:40:17 +0100, David Rientjes <rientjes@google.com>
wrote:
> On Thu, 14 Jan 2010, Roman Jarosz wrote:
>
>> Hi,
>>
>> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
>> kills
>> when I do hard disk intensive tasks (mainly in VirtualBox which is
>> running
>> Windows XP) and IMHO it kills processes even if I have a lot of free
>> memory.
>>
>> Is this a known bug? I have self compiled kernel so I can try patches.
>>
>> Regards
>> Roman Jarosz
>>
>> PS. Please CC me.
>>
>> Jan 7 12:39:27 kedge kernel: X invoked oom-killer: gfp_mask=0x0,
>> order=0,
>> oom_adj=0
>
> The gfp_mask of 0x0 and order of 0 indicate these are triggered by
> pagefaults that end up returning VM_FAULT_OOM. Prior to 2.6.29, the
> current task (X in all cases from your log) would have been SIGKILLed; we
> now call the oom killer instead of kill a memory hogging task so that the
> fault is retried with more success. If you've upgraded from a 2.6.29 or
> later kernel and are only now experiencing these errors, it may indicate
> a
> regression in VM that we need to investigate (and, if so, you may want to
> try merging f50de2d38 from 2.6.33 to see if it helps keep more
> ZONE_NORMAL
> memory available so that such drastic measures aren't necessary).
I only have logs since 2.6.31-rc7 and there is one oom-kill in 2.6.32-rc7
and then the kills in 2.6.32.2.
Nov 25 13:49:04 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Nov 25 13:49:04 kedge kernel: Pid: 1883, comm: X Not tainted 2.6.32-rc7 #1
Nov 25 13:49:04 kedge kernel: Call Trace:
Nov 25 13:49:04 kedge kernel: [<ffffffff8107a66d>] ? 0xffffffff8107a66d
Nov 25 13:49:04 kedge kernel: [<ffffffff8107a953>] ? 0xffffffff8107a953
Nov 25 13:49:04 kedge kernel: [<ffffffff8107aac7>] ? 0xffffffff8107aac7
Nov 25 13:49:04 kedge kernel: [<ffffffff8155453f>] ? 0xffffffff8155453f
Nov 25 13:49:04 kedge kernel: Mem-Info:
Nov 25 13:49:04 kedge kernel: DMA per-cpu:
Nov 25 13:49:04 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Nov 25 13:49:04 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Nov 25 13:49:04 kedge kernel: DMA32 per-cpu:
Nov 25 13:49:04 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 178
Nov 25 13:49:04 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 174
Nov 25 13:49:04 kedge kernel: Normal per-cpu:
Nov 25 13:49:04 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 153
Nov 25 13:49:04 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 81
Nov 25 13:49:04 kedge kernel: active_anon:135012 inactive_anon:77065
isolated_anon:0
Nov 25 13:49:04 kedge kernel: active_file:332368 inactive_file:411112
isolated_file:32
Nov 25 13:49:04 kedge kernel: unevictable:0 dirty:139692 writeback:2395
unstable:0
Nov 25 13:49:04 kedge kernel: free:6869 slab_reclaimable:15618
slab_unreclaimable:7026
Nov 25 13:49:04 kedge kernel: mapped:31999 shmem:26786 pagetables:4497
bounce:0
Nov 25 13:49:04 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:1
60kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15344kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_rec
laimable:0kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaima
ble? no
Nov 25 13:49:04 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Nov 25 13:49:04 kedge kernel: DMA32 free:9856kB min:6084kB low:7604kB
high:9124kB active_anon:327516kB inactive_anon:87488kB active_file:112
2804kB inactive_file:1374360kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:3062688kB mlocked:0kB dirty:440312kB writeback:
5556kB mapped:24652kB shmem:57952kB slab_reclaimable:42492kB
slab_unreclaimable:10528kB kernel_stack:472kB pagetables:3464kB
unstable:0kB bo
unce:0kB writeback_tmp:0kB pages_scanned:384 all_unreclaimable? no
Nov 25 13:49:04 kedge kernel: lowmem_reserve[]: 0 0 946 946
Nov 25 13:49:04 kedge kernel: Normal free:1844kB min:1924kB low:2404kB
high:2884kB active_anon:212532kB inactive_anon:220772kB active_file:2
06668kB inactive_file:269928kB unevictable:0kB isolated(anon):0kB
isolated(file):128kB present:969600kB mlocked:0kB dirty:118456kB writeback
:4024kB mapped:103344kB shmem:49192kB slab_reclaimable:19980kB
slab_unreclaimable:17568kB kernel_stack:1608kB pagetables:14524kB
unstable:0k
B bounce:0kB writeback_tmp:0kB pages_scanned:448 all_unreclaimable? no
Nov 25 13:49:04 kedge kernel: lowmem_reserve[]: 0 0 0 0
Nov 25 13:49:04 kedge kernel: DMA: 0*4kB 2*8kB 1*16kB 2*32kB 1*64kB
2*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15776kB
Nov 25 13:49:04 kedge kernel: DMA32: 300*4kB 4*8kB 29*16kB 1*32kB 1*64kB
1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 1*4096kB = 9856kB
Nov 25 13:49:04 kedge kernel: Normal: 461*4kB 0*8kB 0*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1844kB
Nov 25 13:49:04 kedge kernel: 754208 total pagecache pages
Nov 25 13:49:04 kedge kernel: 64 pages in swap cache
Nov 25 13:49:04 kedge kernel: Swap cache stats: add 357, delete 293, find
2/8
Nov 25 13:49:04 kedge kernel: Free swap = 2006888kB
Nov 25 13:49:04 kedge kernel: Total swap = 2008116kB
Nov 25 13:49:04 kedge kernel: 1032192 pages RAM
Nov 25 13:49:04 kedge kernel: 36869 pages reserved
Nov 25 13:49:04 kedge kernel: 377334 pages shared
Nov 25 13:49:04 kedge kernel: 705565 pages non-shared
Nov 25 13:49:04 kedge kernel: Out of memory: kill process 6816
(services.exe) score 1652318 or a child
Nov 25 13:49:04 kedge kernel: Killed process 6818 (winedevice.exe)
>> Jan 7 12:39:27 kedge kernel: Pid: 1954, comm: X Not tainted 2.6.32.2 #1
>> Jan 7 12:39:27 kedge kernel: Call Trace:
>> Jan 7 12:39:27 kedge kernel: [<ffffffff8107b17d>] ? 0xffffffff8107b17d
>> Jan 7 12:39:27 kedge kernel: [<ffffffff8107b463>] ? 0xffffffff8107b463
>> Jan 7 12:39:27 kedge kernel: [<ffffffff8107b5d7>] ? 0xffffffff8107b5d7
>> Jan 7 12:39:27 kedge kernel: [<ffffffff815581df>] ? 0xffffffff815581df
>
> Can you find out what these symbols are?
Can I somehow get the symbols without recompiling kernel?
I have the source tree with *.o files and other stuff which was created
during compilation.
I've also got the kill in 2.6.33-rc5, what do I have to do to get the
symbols?
Is "Load all symbols for debugging/ksymoops (KALLSYMS)" and
"Compile the kernel with frame pointers (FRAME_POINTER)" enough?
Jan 25 15:51:45 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 25 15:51:45 kedge kernel: Pid: 1904, comm: X Not tainted 2.6.33-rc5 #1
Jan 25 15:51:45 kedge kernel: Call Trace:
Jan 25 15:51:45 kedge kernel: [<ffffffff8107e1a4>] 0xffffffff8107e1a4
Jan 25 15:51:45 kedge kernel: [<ffffffff8107e306>] 0xffffffff8107e306
Jan 25 15:51:45 kedge kernel: [<ffffffff8107e4f0>] 0xffffffff8107e4f0
Jan 25 15:51:45 kedge kernel: [<ffffffff8107e678>] 0xffffffff8107e678
Jan 25 15:51:45 kedge kernel: [<ffffffff81021e60>] 0xffffffff81021e60
Jan 25 15:51:45 kedge kernel: [<ffffffff810221a8>] 0xffffffff810221a8
Jan 25 15:51:45 kedge kernel: [<ffffffff8156f95f>] 0xffffffff8156f95f
Jan 25 15:51:45 kedge kernel: Mem-Info:
Jan 25 15:51:45 kedge kernel: DMA per-cpu:
Jan 25 15:51:45 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 25 15:51:45 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 25 15:51:45 kedge kernel: DMA32 per-cpu:
Jan 25 15:51:45 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 152
Jan 25 15:51:45 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 171
Jan 25 15:51:45 kedge kernel: Normal per-cpu:
Jan 25 15:51:45 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 44
Jan 25 15:51:45 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 167
Jan 25 15:51:45 kedge kernel: active_anon:303490 inactive_anon:130718
isolated_anon:32
Jan 25 15:51:45 kedge kernel: active_file:308170 inactive_file:183887
isolated_file:0
Jan 25 15:51:45 kedge kernel: unevictable:0 dirty:172639 writeback:8741
unstable:0
Jan 25 15:51:45 kedge kernel: free:6871 slab_reclaimable:26390
slab_unreclaimable:11635
Jan 25 15:51:45 kedge kernel: mapped:38879 shmem:29781 pagetables:5198
bounce:0
Jan 25 15:51:45 kedge kernel: DMA free:15764kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:4kB inactive_file:156kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15332kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:4kB slab_unreclaimable:16kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 25 15:51:45 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 25 15:51:45 kedge kernel: DMA32 free:9832kB min:6084kB low:7604kB
high:9124kB active_anon:970168kB inactive_anon:242576kB
active_file:1015796kB inactive_file:619228kB unevictable:0kB
isolated(anon):128kB isolated(file):0kB present:3062688kB mlocked:0kB
dirty:584004kB writeback:31268kB mapped:35252kB shmem:43448kB
slab_reclaimable:85656kB slab_unreclaimable:25596kB kernel_stack:264kB
pagetables:4724kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:238 all_unreclaimable? no
Jan 25 15:51:45 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 25 15:51:45 kedge kernel: Normal free:1888kB min:1924kB low:2404kB
high:2884kB active_anon:243792kB inactive_anon:280296kB
active_file:216880kB inactive_file:116164kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:969600kB mlocked:0kB
dirty:106552kB writeback:3696kB mapped:120264kB shmem:75676kB
slab_reclaimable:19900kB slab_unreclaimable:20928kB kernel_stack:1920kB
pagetables:16068kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:33 all_unreclaimable? no
Jan 25 15:51:45 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 25 15:51:45 kedge kernel: DMA: 1*4kB 2*8kB 2*16kB 3*32kB 2*64kB
3*128kB 3*256kB 2*512kB 3*1024kB 3*2048kB 1*4096kB = 15764kB
Jan 25 15:51:45 kedge kernel: DMA32: 1108*4kB 1*8kB 2*16kB 0*32kB 0*64kB
2*128kB 2*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 9848kB
Jan 25 15:51:45 kedge kernel: Normal: 472*4kB 0*8kB 0*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1888kB
Jan 25 15:51:45 kedge kernel: 522113 total pagecache pages
Jan 25 15:51:45 kedge kernel: 274 pages in swap cache
Jan 25 15:51:45 kedge kernel: Swap cache stats: add 5340, delete 5066,
find 0/0
Jan 25 15:51:45 kedge kernel: Free swap = 1986756kB
Jan 25 15:51:45 kedge kernel: Total swap = 2008116kB
Jan 25 15:51:45 kedge kernel: 1032192 pages RAM
Jan 25 15:51:45 kedge kernel: 49813 pages reserved
Jan 25 15:51:45 kedge kernel: 821582 pages shared
Jan 25 15:51:45 kedge kernel: 260542 pages non-shared
Jan 25 15:51:45 kedge kernel: Out of memory: kill process 1746 (hald)
score 10058 or a child
Jan 25 15:51:45 kedge kernel: Killed process 1747 (hald-runner)
vsz:17860kB, anon-rss:24kB, file-rss:1044kB
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-25 20:47 ` Roman Jarosz
@ 2010-01-26 5:19 ` KOSAKI Motohiro
2010-01-26 7:51 ` A Rojas
` (2 more replies)
0 siblings, 3 replies; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-26 5:19 UTC (permalink / raw)
To: Roman Jarosz
Cc: kosaki.motohiro, lkml, A. Boulan, michael, jcnengel, rientjes,
earny, Jesse Barnes, Eric Anholt
(cc to lots related person)
> On Mon, 25 Jan 2010 02:48:08 +0100, KOSAKI Motohiro
> <kosaki.motohiro@jp.fujitsu.com> wrote:
>
> >> Hi,
> >>
> >> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
> >> kills when I do hard disk intensive tasks (mainly in VirtualBox which is
> >> running Windows XP) and IMHO it kills processes even if I have a lot of
> >> free memory.
> >>
> >> Is this a known bug? I have self compiled kernel so I can try patches.
> >
> > Can you please post your .config?
Hi all,
Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
have any solid evidence.
Can anyone please apply following debug patch and reproduce this issue?
this patch write some debug message into /var/log/messages.
Thanks.
---
mm/memory.c | 45 +++++++++++++++++++++++++++++++++++++--------
1 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 09e4b1b..5c9ebd8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2128,17 +2128,23 @@ reuse:
gotten:
pte_unmap_unlock(page_table, ptl);
- if (unlikely(anon_vma_prepare(vma)))
+ if (unlikely(anon_vma_prepare(vma))) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom;
+ }
if (is_zero_pfn(pte_pfn(orig_pte))) {
new_page = alloc_zeroed_user_highpage_movable(vma, address);
- if (!new_page)
+ if (!new_page) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom;
+ }
} else {
new_page = alloc_page_vma(GFP_HIGHUSER_MOVABLE, vma, address);
- if (!new_page)
+ if (!new_page) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom;
+ }
cow_user_page(new_page, old_page, address, vma);
}
__SetPageUptodate(new_page);
@@ -2153,8 +2159,10 @@ gotten:
unlock_page(old_page);
}
- if (mem_cgroup_newpage_charge(new_page, mm, GFP_KERNEL))
+ if (mem_cgroup_newpage_charge(new_page, mm, GFP_KERNEL)) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom_free_new;
+ }
/*
* Re-check the pte - we dropped the lock
@@ -2272,6 +2280,10 @@ oom:
unwritable_page:
page_cache_release(old_page);
+
+ if (ret & VM_FAULT_OOM)
+ printk(KERN_ERR "do_wp ->page_mkwrite OOM %pf %x\n", vma->vm_ops->page_mkwrite, ret);
+
return ret;
}
@@ -2670,15 +2682,21 @@ static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
/* Allocate our own private page. */
pte_unmap(page_table);
- if (unlikely(anon_vma_prepare(vma)))
+ if (unlikely(anon_vma_prepare(vma))) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom;
+ }
page = alloc_zeroed_user_highpage_movable(vma, address);
- if (!page)
+ if (!page) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom;
+ }
__SetPageUptodate(page);
- if (mem_cgroup_newpage_charge(page, mm, GFP_KERNEL))
+ if (mem_cgroup_newpage_charge(page, mm, GFP_KERNEL)) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
goto oom_free_page;
+ }
entry = mk_pte(page, vma->vm_page_prot);
if (vma->vm_flags & VM_WRITE)
@@ -2742,8 +2760,12 @@ static int __do_fault(struct mm_struct *mm, struct vm_area_struct *vma,
vmf.page = NULL;
ret = vma->vm_ops->fault(vma, &vmf);
- if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))
+ if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE))) {
+ if (ret & VM_FAULT_OOM)
+ printk(KERN_ERR "->fault OOM %pf %x %x\n", vma->vm_ops->fault, ret, flags);
+
return ret;
+ }
if (unlikely(PageHWPoison(vmf.page))) {
if (ret & VM_FAULT_LOCKED)
@@ -2768,16 +2790,19 @@ static int __do_fault(struct mm_struct *mm, struct vm_area_struct *vma,
if (!(vma->vm_flags & VM_SHARED)) {
anon = 1;
if (unlikely(anon_vma_prepare(vma))) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
ret = VM_FAULT_OOM;
goto out;
}
page = alloc_page_vma(GFP_HIGHUSER_MOVABLE,
vma, address);
if (!page) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
ret = VM_FAULT_OOM;
goto out;
}
if (mem_cgroup_newpage_charge(page, mm, GFP_KERNEL)) {
+ printk(KERN_ERR "OOM at %s:%d\n", __FILE__, __LINE__);
ret = VM_FAULT_OOM;
page_cache_release(page);
goto out;
@@ -2896,6 +2921,10 @@ out:
unwritable_page:
page_cache_release(page);
+
+ if (ret & VM_FAULT_OOM)
+ printk(KERN_ERR "->page_mkwrite OOM %pf %x %x\n", vma->vm_ops->page_mkwrite, ret, flags);
+
return ret;
}
--
1.6.5.2
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 5:19 ` KOSAKI Motohiro
@ 2010-01-26 7:51 ` A Rojas
2010-01-26 9:06 ` Roman Jarosz
2010-01-26 13:57 ` Pekka Enberg
2 siblings, 0 replies; 52+ messages in thread
From: A Rojas @ 2010-01-26 7:51 UTC (permalink / raw)
To: linux-kernel
KOSAKI Motohiro wrote:
>
> Hi all,
>
> Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> have any solid evidence.
Hi,
I have the same issue in i686 (intel i915 too)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 5:19 ` KOSAKI Motohiro
2010-01-26 7:51 ` A Rojas
@ 2010-01-26 9:06 ` Roman Jarosz
2010-01-26 11:07 ` KOSAKI Motohiro
2010-01-26 13:57 ` Pekka Enberg
2 siblings, 1 reply; 52+ messages in thread
From: Roman Jarosz @ 2010-01-26 9:06 UTC (permalink / raw)
To: lkml
On Tue, 26 Jan 2010 06:19:23 +0100, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> (cc to lots related person)
>
>> On Mon, 25 Jan 2010 02:48:08 +0100, KOSAKI Motohiro
>> <kosaki.motohiro@jp.fujitsu.com> wrote:
>>
>> >> Hi,
>> >>
>> >> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
>> >> kills when I do hard disk intensive tasks (mainly in VirtualBox
>> which is
>> >> running Windows XP) and IMHO it kills processes even if I have a lot
>> of
>> >> free memory.
>> >>
>> >> Is this a known bug? I have self compiled kernel so I can try
>> patches.
>> >
>> > Can you please post your .config?
>
> Hi all,
>
> Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> have any solid evidence.
> Can anyone please apply following debug patch and reproduce this issue?
>
> this patch write some debug message into /var/log/messages.
>
Here it is
Jan 26 09:34:32 kedge kernel: ->fault OOM shmem_fault 1 1
Jan 26 09:34:32 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
oom_adj=0
Jan 26 09:34:32 kedge kernel: Pid: 1927, comm: X Not tainted 2.6.33-rc5 #3
Jan 26 09:34:32 kedge kernel: Call Trace:
Jan 26 09:34:32 kedge kernel: [<ffffffff8107feb4>] T.350+0x54/0x140
Jan 26 09:34:32 kedge kernel: [<ffffffff81080016>] T.349+0x76/0x140
Jan 26 09:34:32 kedge kernel: [<ffffffff81080200>]
__out_of_memory+0x120/0x190
Jan 26 09:34:32 kedge kernel: [<ffffffff81080388>]
pagefault_out_of_memory+0x48/0x90
Jan 26 09:34:32 kedge kernel: [<ffffffff81021eb0>] mm_fault_error+0x40/0xc0
Jan 26 09:34:33 kedge kernel: [<ffffffff810221f8>]
do_page_fault+0x2c8/0x2d0
Jan 26 09:34:35 kedge kernel: [<ffffffff815719df>] page_fault+0x1f/0x30
Jan 26 09:34:35 kedge kernel: Mem-Info:
Jan 26 09:34:35 kedge kernel: DMA per-cpu:
Jan 26 09:34:35 kedge kernel: CPU 0: hi: 0, btch: 1 usd: 0
Jan 26 09:34:35 kedge kernel: CPU 1: hi: 0, btch: 1 usd: 0
Jan 26 09:34:35 kedge kernel: DMA32 per-cpu:
Jan 26 09:34:35 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 135
Jan 26 09:34:35 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 119
Jan 26 09:34:35 kedge kernel: Normal per-cpu:
Jan 26 09:34:35 kedge kernel: CPU 0: hi: 186, btch: 31 usd: 124
Jan 26 09:34:35 kedge kernel: CPU 1: hi: 186, btch: 31 usd: 0
Jan 26 09:34:35 kedge kernel: active_anon:299484 inactive_anon:124767
isolated_anon:32
Jan 26 09:34:35 kedge kernel: active_file:318642 inactive_file:192171
isolated_file:0
Jan 26 09:34:35 kedge kernel: unevictable:2 dirty:113272 writeback:19224
unstable:0
Jan 26 09:34:35 kedge kernel: free:6859 slab_reclaimable:19340
slab_unreclaimable:10057
Jan 26 09:34:35 kedge kernel: mapped:27902 shmem:50780 pagetables:4901
bounce:0
Jan 26 09:34:35 kedge kernel: DMA free:15776kB min:28kB low:32kB high:40kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:160kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15332kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
Jan 26 09:34:35 kedge kernel: lowmem_reserve[]: 0 2990 3937 3937
Jan 26 09:34:35 kedge kernel: DMA32 free:9792kB min:6084kB low:7604kB
high:9124kB active_anon:936684kB inactive_anon:237096kB
active_file:1032028kB inactive_file:636296kB unevictable:8kB
isolated(anon):0kB isolated(file):0kB present:3062688kB mlocked:8kB
dirty:381208kB writeback:65944kB mapped:68072kB shmem:70336kB
slab_reclaimable:54692kB slab_unreclaimable:18084kB kernel_stack:128kB
pagetables:2968kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:240 all_unreclaimable? no
Jan 26 09:34:35 kedge kernel: lowmem_reserve[]: 0 0 946 946
Jan 26 09:34:35 kedge kernel: Normal free:1868kB min:1924kB low:2404kB
high:2884kB active_anon:261252kB inactive_anon:261972kB
active_file:242540kB inactive_file:132228kB unevictable:0kB
isolated(anon):128kB isolated(file):0kB present:969600kB mlocked:0kB
dirty:71880kB writeback:10952kB mapped:43536kB shmem:132784kB
slab_reclaimable:22668kB slab_unreclaimable:22136kB kernel_stack:1984kB
pagetables:16636kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:100 all_unreclaimable? no
Jan 26 09:34:35 kedge kernel: lowmem_reserve[]: 0 0 0 0
Jan 26 09:34:35 kedge kernel: DMA: 0*4kB 2*8kB 1*16kB 2*32kB 1*64kB
2*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 2*4096kB = 15776kB
Jan 26 09:34:35 kedge kernel: DMA32: 158*4kB 7*8kB 10*16kB 6*32kB 1*64kB
0*128kB 4*256kB 1*512kB 1*1024kB 1*2048kB 1*4096kB = 9808kB
Jan 26 09:34:35 kedge kernel: Normal: 467*4kB 0*8kB 0*16kB 0*32kB 0*64kB
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1868kB
Jan 26 09:34:35 kedge kernel: 561725 total pagecache pages
Jan 26 09:34:35 kedge kernel: 77 pages in swap cache
Jan 26 09:34:35 kedge kernel: Swap cache stats: add 6320, delete 6243,
find 0/0
Jan 26 09:34:35 kedge kernel: Free swap = 1982844kB
Jan 26 09:34:35 kedge kernel: Total swap = 2008116kB
Jan 26 09:34:35 kedge kernel: 1032192 pages RAM
Jan 26 09:34:35 kedge kernel: 49925 pages reserved
Jan 26 09:34:35 kedge kernel: 855983 pages shared
Jan 26 09:34:35 kedge kernel: 172671 pages non-shared
Jan 26 09:34:35 kedge kernel: Out of memory: kill process 1765 (hald)
score 10056 or a child
Jan 26 09:34:35 kedge kernel: Killed process 1766 (hald-runner)
vsz:17860kB, anon-rss:24kB, file-rss:732kB
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 9:06 ` Roman Jarosz
@ 2010-01-26 11:07 ` KOSAKI Motohiro
2010-01-26 12:33 ` Chris Wilson
2010-01-26 13:41 ` OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
0 siblings, 2 replies; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-26 11:07 UTC (permalink / raw)
To: Roman Jarosz
Cc: kosaki.motohiro, lkml, A Rojas, Hugh Dickins, A. Boulan, michael,
jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt,
Chris Wilson
(Restore all cc and add Hugh and Chris)
> > Hi all,
> >
> > Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> > have any solid evidence.
> > Can anyone please apply following debug patch and reproduce this issue?
> >
> > this patch write some debug message into /var/log/messages.
> >
>
> Here it is
>
> Jan 26 09:34:32 kedge kernel: ->fault OOM shmem_fault 1 1
> Jan 26 09:34:32 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
> oom_adj=0
> Jan 26 09:34:32 kedge kernel: Pid: 1927, comm: X Not tainted 2.6.33-rc5 #3
Very thank you!!
Current status and analysis are
- OOM is invoked by VM_FAULT_OOM in page fault
- GEM use lots shmem internally. i915 use GEM.
- VM_FAULT_OOM is created by shmem.
- shmem allocate some memory by using mapping_gfp_mask(inode->i_mapping).
and if allocation failed, it can return -ENOMEM and -ENOMEM generate VM_FAULT_OOM.
- But, GEM have following code.
drm_gem.c drm_gem_object_alloc()
--------------------
obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
(snip)
/* Basically we want to disable the OOM killer and handle ENOMEM
* ourselves by sacrificing pages from cached buffers.
* XXX shmem_file_[gs]et_gfp_mask()
*/
mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
GFP_HIGHUSER |
__GFP_COLD |
__GFP_FS |
__GFP_RECLAIMABLE |
__GFP_NORETRY |
__GFP_NOWARN |
__GFP_NOMEMALLOC);
This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
GEM can't handle nor recover it. I suspect following commit is wrong.
----------------------------------------------------
commit 07f73f6912667621276b002e33844ef283d98203
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 14 16:50:30 2009 +0100
drm/i915: Improve behaviour under memory pressure
Due to the necessity of having to take the struct_mutex, the i915
shrinker can not free the inactive lists if we fail to allocate memory
whilst processing a batch buffer, triggering an OOM and an ENOMEM that
is reported back to userspace. In order to fare better under such
circumstances we need to manually retry a failed allocation after
evicting inactive buffers.
To do so involves 3 steps:
1. Marking the backing shm pages as NORETRY.
2. Updating the get_pages() callers to evict something on failure and then
retry.
3. Revamping the evict something logic to be smarter about the required
buffer size and prefer to use volatile or clean inactive pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
----------------------------------------------------
but unfortunatelly it can't revert easily.
So, Can you please try following partial revert patch?
>From a27115f93d4f3ff6538860e69a7b444761cef91b Mon Sep 17 00:00:00 2001
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date: Tue, 26 Jan 2010 19:51:57 +0900
Subject: [PATCH] Revert NORETRY
---
drivers/gpu/drm/drm_gem.c | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e9dbb48..8bf3770 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
if (IS_ERR(obj->filp))
goto free;
- /* Basically we want to disable the OOM killer and handle ENOMEM
- * ourselves by sacrificing pages from cached buffers.
- * XXX shmem_file_[gs]et_gfp_mask()
- */
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
- GFP_HIGHUSER |
- __GFP_COLD |
- __GFP_FS |
- __GFP_RECLAIMABLE |
- __GFP_NORETRY |
- __GFP_NOWARN |
- __GFP_NOMEMALLOC);
-
kref_init(&obj->refcount);
kref_init(&obj->handlecount);
obj->size = size;
--
1.6.5.2
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 11:07 ` KOSAKI Motohiro
@ 2010-01-26 12:33 ` Chris Wilson
2010-01-26 13:03 ` KOSAKI Motohiro
2010-01-26 13:41 ` OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
1 sibling, 1 reply; 52+ messages in thread
From: Chris Wilson @ 2010-01-26 12:33 UTC (permalink / raw)
To: KOSAKI Motohiro, Roman Jarosz
Cc: kosaki.motohiro, lkml, A Rojas, Hugh Dickins, A. Boulan, michael,
jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt
On Tue, 26 Jan 2010 20:07:43 +0900 (JST), KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> (snip)
> /* Basically we want to disable the OOM killer and handle ENOMEM
> * ourselves by sacrificing pages from cached buffers.
> * XXX shmem_file_[gs]et_gfp_mask()
> */
> mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> GFP_HIGHUSER |
> __GFP_COLD |
> __GFP_FS |
> __GFP_RECLAIMABLE |
> __GFP_NORETRY |
> __GFP_NOWARN |
> __GFP_NOMEMALLOC);
>
>
> This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
> GEM can't handle nor recover it. I suspect following commit is wrong.
Indeed, the NORETRY flag is required for the inode mapping routines to
return ENOMEM instead of triggering the OOM killer themselves. GEM has
code to handle the ENOMEM as returned from shmem (please at least read the
code before commenting, and comments are appreciated), by attempting to
free up some of its own inactive buffers before retrying the allocation
(with NORETRY removed, so the OOM killer will be invoked on the second
instance). The reason for this convoluted approach is that GEM's inactive
list shrinker requires the struct mutex and so cannot be run when GEM
itself is attempting and failing to allocate memory. We could recover from
more situations if we made some more invasive changes to our locking.
This is without a doubt an area that needs improvement.
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 12:33 ` Chris Wilson
@ 2010-01-26 13:03 ` KOSAKI Motohiro
2010-01-26 13:18 ` Chris Wilson
0 siblings, 1 reply; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-26 13:03 UTC (permalink / raw)
To: Chris Wilson
Cc: Roman Jarosz, lkml, A Rojas, Hugh Dickins, A. Boulan, michael,
jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt
>> This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
>> GEM can't handle nor recover it. I suspect following commit is wrong.
>
> Indeed, the NORETRY flag is required for the inode mapping routines to
> return ENOMEM instead of triggering the OOM killer themselves. GEM has
> code to handle the ENOMEM as returned from shmem (please at least read the
> code before commenting, and comments are appreciated), by attempting to
> free up some of its own inactive buffers before retrying the allocation
> (with NORETRY removed, so the OOM killer will be invoked on the second
> instance). The reason for this convoluted approach is that GEM's inactive
> list shrinker requires the struct mutex and so cannot be run when GEM
> itself is attempting and failing to allocate memory. We could recover from
> more situations if we made some more invasive changes to our locking.
>
> This is without a doubt an area that needs improvement.
Please consider to revert such commit at once. Lots people reported
the same issue.
I really hope to stop bug report storm.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 13:03 ` KOSAKI Motohiro
@ 2010-01-26 13:18 ` Chris Wilson
2010-01-26 13:59 ` Michael Reinelt
2010-01-27 0:50 ` KOSAKI Motohiro
0 siblings, 2 replies; 52+ messages in thread
From: Chris Wilson @ 2010-01-26 13:18 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Roman Jarosz, lkml, A Rojas, Hugh Dickins, A. Boulan, michael,
jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt
On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> Please consider to revert such commit at once. Lots people reported
> the same issue.
> I really hope to stop bug report storm.
Your CC did not reference the problem that you were discussing, nor that
it is even easier to trigger an OOM without the shrinker. Memory
exhaustion due to the excess usage of surfaces from userspace is not a new
issuer. So what is the problem you have encountered and how does running
the OOM killer earlier fix the issue of triggering the OOM killer?
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 11:07 ` KOSAKI Motohiro
2010-01-26 12:33 ` Chris Wilson
@ 2010-01-26 13:41 ` Roman Jarosz
2010-01-27 0:14 ` KOSAKI Motohiro
1 sibling, 1 reply; 52+ messages in thread
From: Roman Jarosz @ 2010-01-26 13:41 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: lkml, A Rojas, Hugh Dickins, A. Boulan, michael, jcnengel,
rientjes, earny, Jesse Barnes, Eric Anholt, Chris Wilson
On Tue, 26 Jan 2010 12:07:43 +0100, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> (Restore all cc and add Hugh and Chris)
>
>
>> > Hi all,
>> >
>> > Strangely, all reproduce machine are x86_64 with Intel i915. but I
>> don't
>> > have any solid evidence.
>> > Can anyone please apply following debug patch and reproduce this
>> issue?
>> >
>> > this patch write some debug message into /var/log/messages.
>> >
>>
>> Here it is
>>
>> Jan 26 09:34:32 kedge kernel: ->fault OOM shmem_fault 1 1
>> Jan 26 09:34:32 kedge kernel: X invoked oom-killer: gfp_mask=0x0,
>> order=0,
>> oom_adj=0
>> Jan 26 09:34:32 kedge kernel: Pid: 1927, comm: X Not tainted 2.6.33-rc5
>> #3
>
>
> Very thank you!!
>
> Current status and analysis are
> - OOM is invoked by VM_FAULT_OOM in page fault
> - GEM use lots shmem internally. i915 use GEM.
> - VM_FAULT_OOM is created by shmem.
> - shmem allocate some memory by using
> mapping_gfp_mask(inode->i_mapping).
> and if allocation failed, it can return -ENOMEM and -ENOMEM generate
> VM_FAULT_OOM.
> - But, GEM have following code.
>
>
> drm_gem.c drm_gem_object_alloc()
> --------------------
> obj->filp = shmem_file_setup("drm mm object", size,
> VM_NORESERVE);
> (snip)
> /* Basically we want to disable the OOM killer and handle ENOMEM
> * ourselves by sacrificing pages from cached buffers.
> * XXX shmem_file_[gs]et_gfp_mask()
> */
> mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> GFP_HIGHUSER |
> __GFP_COLD |
> __GFP_FS |
> __GFP_RECLAIMABLE |
> __GFP_NORETRY |
> __GFP_NOWARN |
> __GFP_NOMEMALLOC);
>
>
> This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
> GEM can't handle nor recover it. I suspect following commit is wrong.
>
> ----------------------------------------------------
> commit 07f73f6912667621276b002e33844ef283d98203
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Mon Sep 14 16:50:30 2009 +0100
>
> drm/i915: Improve behaviour under memory pressure
>
> Due to the necessity of having to take the struct_mutex, the i915
> shrinker can not free the inactive lists if we fail to allocate
> memory
> whilst processing a batch buffer, triggering an OOM and an ENOMEM
> that
> is reported back to userspace. In order to fare better under such
> circumstances we need to manually retry a failed allocation after
> evicting inactive buffers.
>
> To do so involves 3 steps:
> 1. Marking the backing shm pages as NORETRY.
> 2. Updating the get_pages() callers to evict something on failure
> and then
> retry.
> 3. Revamping the evict something logic to be smarter about the
> required
> buffer size and prefer to use volatile or clean inactive pages.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ----------------------------------------------------
>
>
> but unfortunatelly it can't revert easily.
> So, Can you please try following partial revert patch?
>
>
>
> From a27115f93d4f3ff6538860e69a7b444761cef91b Mon Sep 17 00:00:00 2001
> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Date: Tue, 26 Jan 2010 19:51:57 +0900
> Subject: [PATCH] Revert NORETRY
>
> ---
> drivers/gpu/drm/drm_gem.c | 13 -------------
> 1 files changed, 0 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index e9dbb48..8bf3770 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t
> size)
> if (IS_ERR(obj->filp))
> goto free;
> - /* Basically we want to disable the OOM killer and handle ENOMEM
> - * ourselves by sacrificing pages from cached buffers.
> - * XXX shmem_file_[gs]et_gfp_mask()
> - */
> - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> - GFP_HIGHUSER |
> - __GFP_COLD |
> - __GFP_FS |
> - __GFP_RECLAIMABLE |
> - __GFP_NORETRY |
> - __GFP_NOWARN |
> - __GFP_NOMEMALLOC);
> -
> kref_init(&obj->refcount);
> kref_init(&obj->handlecount);
> obj->size = size;
I've applied this patch and I'm testing it right now.
Btw. what this patch will do from user(my) point of view?
Regards
Roman
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 5:19 ` KOSAKI Motohiro
2010-01-26 7:51 ` A Rojas
2010-01-26 9:06 ` Roman Jarosz
@ 2010-01-26 13:57 ` Pekka Enberg
2 siblings, 0 replies; 52+ messages in thread
From: Pekka Enberg @ 2010-01-26 13:57 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Roman Jarosz, lkml, A. Boulan, michael, jcnengel, rientjes,
earny, Jesse Barnes, Eric Anholt, jithin1987
On Tue, Jan 26, 2010 at 7:19 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> (cc to lots related person)
>
>> On Mon, 25 Jan 2010 02:48:08 +0100, KOSAKI Motohiro
>> <kosaki.motohiro@jp.fujitsu.com> wrote:
>>
>> >> Hi,
>> >>
>> >> since kernel 2.6.32.2 (also tried 2.6.32.3) I get a lot of oom-killer
>> >> kills when I do hard disk intensive tasks (mainly in VirtualBox which is
>> >> running Windows XP) and IMHO it kills processes even if I have a lot of
>> >> free memory.
>> >>
>> >> Is this a known bug? I have self compiled kernel so I can try patches.
>> >
>> > Can you please post your .config?
>
> Hi all,
>
> Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> have any solid evidence.
The same oops seems to appear in an unrelated "screen going blank" bug
report (it's the second to last oops):
http://bugzilla.kernel.org/show_bug.cgi?id=15015
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 13:18 ` Chris Wilson
@ 2010-01-26 13:59 ` Michael Reinelt
2010-01-26 14:07 ` Michael Reinelt
2010-01-27 0:50 ` KOSAKI Motohiro
1 sibling, 1 reply; 52+ messages in thread
From: Michael Reinelt @ 2010-01-26 13:59 UTC (permalink / raw)
To: Chris Wilson
Cc: KOSAKI Motohiro, Roman Jarosz, lkml, A Rojas, Hugh Dickins,
A. Boulan, jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt
Chris Wilson schrieb:
> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>> Please consider to revert such commit at once. Lots people reported
>> the same issue.
>> I really hope to stop bug report storm.
>
> Your CC did not reference the problem that you were discussing, nor that
> it is even easier to trigger an OOM without the shrinker. Memory
> exhaustion due to the excess usage of surfaces from userspace is not a new
> issuer. So what is the problem you have encountered and how does running
> the OOM killer earlier fix the issue of triggering the OOM killer?
>
To end this discussion: I just had a OOM with the GEM / shmem partial revert patch from Motohiro :-(
Unfortunately without Motohiro's oom-debug patch applied :-(
as a non-git-user I have to manually patch memory.c, but I hope I can get things right. I will provide results ASAP.
--
Michael Reinelt <michael@reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 13:59 ` Michael Reinelt
@ 2010-01-26 14:07 ` Michael Reinelt
0 siblings, 0 replies; 52+ messages in thread
From: Michael Reinelt @ 2010-01-26 14:07 UTC (permalink / raw)
To: Chris Wilson
Cc: KOSAKI Motohiro, Roman Jarosz, lkml, A Rojas, Hugh Dickins,
A. Boulan, jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt
Michael Reinelt schrieb:
>
> Chris Wilson schrieb:
>> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>>> Please consider to revert such commit at once. Lots people reported
>>> the same issue.
>>> I really hope to stop bug report storm.
>> Your CC did not reference the problem that you were discussing, nor that
>> it is even easier to trigger an OOM without the shrinker. Memory
>> exhaustion due to the excess usage of surfaces from userspace is not a new
>> issuer. So what is the problem you have encountered and how does running
>> the OOM killer earlier fix the issue of triggering the OOM killer?
>>
>
> To end this discussion: I just had a OOM with the GEM / shmem partial revert patch from Motohiro :-(
>
> Unfortunately without Motohiro's oom-debug patch applied :-(
>
> as a non-git-user I have to manually patch memory.c, but I hope I can get things right. I will provide results ASAP.
Sorry sorry sorry... false alarm. One should also *install* a new kernel after compiling...
I'll give it another try, this time with OOM debugging applied.
sorry for the noise...
--
Michael Reinelt <michael@reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 13:41 ` OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
@ 2010-01-27 0:14 ` KOSAKI Motohiro
2010-01-27 9:53 ` Roman Jarosz
0 siblings, 1 reply; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-27 0:14 UTC (permalink / raw)
To: Roman Jarosz
Cc: kosaki.motohiro, lkml, A Rojas, Hugh Dickins, A. Boulan, michael,
jcnengel, rientjes, earny, Jesse Barnes, Eric Anholt,
Chris Wilson
> > - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> > - GFP_HIGHUSER |
> > - __GFP_COLD |
> > - __GFP_FS |
> > - __GFP_RECLAIMABLE |
> > - __GFP_NORETRY |
> > - __GFP_NOWARN |
> > - __GFP_NOMEMALLOC);
> > -
> > kref_init(&obj->refcount);
> > kref_init(&obj->handlecount);
> > obj->size = size;
>
> I've applied this patch and I'm testing it right now.
> Btw. what this patch will do from user(my) point of view?
OOM Killer disappear :)
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-26 13:18 ` Chris Wilson
2010-01-26 13:59 ` Michael Reinelt
@ 2010-01-27 0:50 ` KOSAKI Motohiro
2010-01-27 9:56 ` Pekka Enberg
1 sibling, 1 reply; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-27 0:50 UTC (permalink / raw)
To: Chris Wilson
Cc: kosaki.motohiro, Roman Jarosz, lkml, A Rojas, Hugh Dickins,
A. Boulan, michael, jcnengel, rientjes, earny, Jesse Barnes,
Eric Anholt
> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > Please consider to revert such commit at once. Lots people reported
> > the same issue.
> > I really hope to stop bug report storm.
>
> Your CC did not reference the problem that you were discussing, nor that
> it is even easier to trigger an OOM without the shrinker. Memory
> exhaustion due to the excess usage of surfaces from userspace is not a new
> issuer. So what is the problem you have encountered and how does running
> the OOM killer earlier fix the issue of triggering the OOM killer?
Why do you bother easy googling?
example.
1) http://bugzilla.kernel.org/show_bug.cgi?id=14933
Subject : OOM killer unexpectedly called with kernel 2.6.32
Submitter : "A. Boulan" <arnaud.boulan@libertysurf.fr>
Date : 2009-12-24 23:42
References : http://marc.info/?l=linux-kernel&m=126169821317492&w=4
2) http://bugzilla.kernel.org/show_bug.cgi?id=15015
Subject: blank screen at random times in laptop when sitting idle
From: Jithin Emmanuel
Date: 2010-01-09 16:48:23
see comment #2
3) http://bugzilla.kernel.org/show_bug.cgi?id=15058
From: Michael Reinelt
Date: 2010-01-14 16:39:51
4) Subject: Re: OOM kernel behaviour
From: David John <davidjon@xenontk.org>
Mon, 07 Dec 2009 11:04:24 +0530
5) This thread
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-27 0:14 ` KOSAKI Motohiro
@ 2010-01-27 9:53 ` Roman Jarosz
0 siblings, 0 replies; 52+ messages in thread
From: Roman Jarosz @ 2010-01-27 9:53 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: lkml, A Rojas, Hugh Dickins, A. Boulan, michael, jcnengel,
rientjes, earny, Jesse Barnes, Eric Anholt, Chris Wilson
On Wed, 27 Jan 2010 01:14:44 +0100, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> > - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
>> > - GFP_HIGHUSER |
>> > - __GFP_COLD |
>> > - __GFP_FS |
>> > - __GFP_RECLAIMABLE |
>> > - __GFP_NORETRY |
>> > - __GFP_NOWARN |
>> > - __GFP_NOMEMALLOC);
>> > -
>> > kref_init(&obj->refcount);
>> > kref_init(&obj->handlecount);
>> > obj->size = size;
>>
>> I've applied this patch and I'm testing it right now.
>> Btw. what this patch will do from user(my) point of view?
>
> OOM Killer disappear :)
Looks like the patch works... no oom kills so far.
Thanks!
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-27 0:50 ` KOSAKI Motohiro
@ 2010-01-27 9:56 ` Pekka Enberg
2010-01-27 10:55 ` Linus Torvalds
0 siblings, 1 reply; 52+ messages in thread
From: Pekka Enberg @ 2010-01-27 9:56 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Chris Wilson, Roman Jarosz, lkml, A Rojas, Hugh Dickins,
A. Boulan, michael, jcnengel, rientjes, earny, Jesse Barnes,
Eric Anholt, Linus Torvalds, Andrew Morton
On Wed, Jan 27, 2010 at 2:50 AM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> On Tue, 26 Jan 2010 22:03:06 +0900, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>> > Please consider to revert such commit at once. Lots people reported
>> > the same issue.
>> > I really hope to stop bug report storm.
>>
>> Your CC did not reference the problem that you were discussing, nor that
>> it is even easier to trigger an OOM without the shrinker. Memory
>> exhaustion due to the excess usage of surfaces from userspace is not a new
>> issuer. So what is the problem you have encountered and how does running
>> the OOM killer earlier fix the issue of triggering the OOM killer?
>
> Why do you bother easy googling?
>
> example.
>
> 1) http://bugzilla.kernel.org/show_bug.cgi?id=14933
> Subject : OOM killer unexpectedly called with kernel 2.6.32
> Submitter : "A. Boulan" <arnaud.boulan@libertysurf.fr>
> Date : 2009-12-24 23:42
> References : http://marc.info/?l=linux-kernel&m=126169821317492&w=4
>
> 2) http://bugzilla.kernel.org/show_bug.cgi?id=15015
> Subject: blank screen at random times in laptop when sitting idle
> From: Jithin Emmanuel
> Date: 2010-01-09 16:48:23
>
> see comment #2
>
> 3) http://bugzilla.kernel.org/show_bug.cgi?id=15058
> From: Michael Reinelt
> Date: 2010-01-14 16:39:51
>
> 4) Subject: Re: OOM kernel behaviour
> From: David John <davidjon@xenontk.org>
> Mon, 07 Dec 2009 11:04:24 +0530
>
> 5) This thread
Yes, we're very late in 2.6.33 cycle. Chris/Jesse, please apply
Motohiro-san's patch or revert the commit.
Pekka
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-27 9:56 ` Pekka Enberg
@ 2010-01-27 10:55 ` Linus Torvalds
2010-01-27 11:12 ` Pekka Enberg
2010-01-27 11:14 ` [PATCH] drm/i915: Selectively enable self-reclaim Chris Wilson
0 siblings, 2 replies; 52+ messages in thread
From: Linus Torvalds @ 2010-01-27 10:55 UTC (permalink / raw)
To: Pekka Enberg
Cc: KOSAKI Motohiro, Chris Wilson, Roman Jarosz, lkml, A Rojas,
Hugh Dickins, A. Boulan, michael, jcnengel, rientjes, earny,
Jesse Barnes, Eric Anholt, Andrew Morton
On Wed, 27 Jan 2010, Pekka Enberg wrote:
>
> Yes, we're very late in 2.6.33 cycle. Chris/Jesse, please apply
> Motohiro-san's patch or revert the commit.
I assume you're talking about reverting commit 07f73f691 ("drm/i915:
Improve behaviour under memory pressure").
Motohiro-san's patch didn't have a sign-off or a commit message. I guess I
could cobble some commit message together from the thread, but it would be
good if somebody involved with the code were to do so. Please?
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: OOM-Killer kills too much with 2.6.32.2
2010-01-27 10:55 ` Linus Torvalds
@ 2010-01-27 11:12 ` Pekka Enberg
2010-01-27 11:14 ` [PATCH] drm/i915: Selectively enable self-reclaim Chris Wilson
1 sibling, 0 replies; 52+ messages in thread
From: Pekka Enberg @ 2010-01-27 11:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: KOSAKI Motohiro, Chris Wilson, Roman Jarosz, lkml, A Rojas,
Hugh Dickins, A. Boulan, michael, jcnengel, rientjes, earny,
Jesse Barnes, Eric Anholt, Andrew Morton
Hi Linus,
Linus Torvalds kirjoitti:
> On Wed, 27 Jan 2010, Pekka Enberg wrote:
>> Yes, we're very late in 2.6.33 cycle. Chris/Jesse, please apply
>> Motohiro-san's patch or revert the commit.
>
> I assume you're talking about reverting commit 07f73f691 ("drm/i915:
> Improve behaviour under memory pressure").
Yup.
> Motohiro-san's patch didn't have a sign-off or a commit message. I guess I
> could cobble some commit message together from the thread, but it would be
> good if somebody involved with the code were to do so. Please?
I wasn't involved with the actual patch so I'll just let Motohiro-san,
Chris, or Jesse handle that.
Pekka
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 10:55 ` Linus Torvalds
2010-01-27 11:12 ` Pekka Enberg
@ 2010-01-27 11:14 ` Chris Wilson
2010-01-27 11:20 ` Pekka Enberg
` (2 more replies)
1 sibling, 3 replies; 52+ messages in thread
From: Chris Wilson @ 2010-01-27 11:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx, Chris Wilson,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
Having missed the ENOMEM return via i915_gem_fault(), there are probably
other paths that I also missed. By not enabling NORETRY by default these
paths can run the shrinker and take memory from the system (but not from
our own inactive lists because our shrinker can not run whilst we hold
the struct mutex) and this may allow the system to survive a little longer
whilst our drivers consume all available memory.
References:
OOM killer unexpectedly called with kernel 2.6.32
http://bugzilla.kernel.org/show_bug.cgi?id=14933
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
---
drivers/gpu/drm/drm_gem.c | 13 -------------
drivers/gpu/drm/i915/i915_gem.c | 22 ++++++++++------------
2 files changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e9dbb48..8bf3770 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
if (IS_ERR(obj->filp))
goto free;
- /* Basically we want to disable the OOM killer and handle ENOMEM
- * ourselves by sacrificing pages from cached buffers.
- * XXX shmem_file_[gs]et_gfp_mask()
- */
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
- GFP_HIGHUSER |
- __GFP_COLD |
- __GFP_FS |
- __GFP_RECLAIMABLE |
- __GFP_NORETRY |
- __GFP_NOWARN |
- __GFP_NOMEMALLOC);
-
kref_init(&obj->refcount);
kref_init(&obj->handlecount);
obj->size = size;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 28b8f03..1ef5b54 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -336,25 +336,25 @@ i915_gem_object_set_page_gfp_mask (struct drm_gem_object *obj, gfp_t gfp)
static int
i915_gem_object_get_pages_or_evict(struct drm_gem_object *obj)
{
+ gfp_t gfp;
int ret;
+ gfp = i915_gem_object_get_page_gfp_mask(obj);
+ i915_gem_object_set_page_gfp_mask(obj, gfp | __GFP_NORETRY | __GFP_NOWARN);
ret = i915_gem_object_get_pages(obj);
+ i915_gem_object_set_page_gfp_mask (obj, gfp);
/* If we've insufficient memory to map in the pages, attempt
* to make some space by throwing out some old buffers.
*/
if (ret == -ENOMEM) {
struct drm_device *dev = obj->dev;
- gfp_t gfp;
ret = i915_gem_evict_something(dev, obj->size);
if (ret)
return ret;
- gfp = i915_gem_object_get_page_gfp_mask(obj);
- i915_gem_object_set_page_gfp_mask(obj, gfp & ~__GFP_NORETRY);
ret = i915_gem_object_get_pages(obj);
- i915_gem_object_set_page_gfp_mask (obj, gfp);
}
return ret;
@@ -2580,6 +2580,7 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
struct drm_i915_gem_object *obj_priv = obj->driver_private;
struct drm_mm_node *free_space;
bool retry_alloc = false;
+ gfp_t gfp;
int ret;
if (obj_priv->madv != I915_MADV_WILLNEED) {
@@ -2623,15 +2624,12 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
DRM_INFO("Binding object of size %zd at 0x%08x\n",
obj->size, obj_priv->gtt_offset);
#endif
- if (retry_alloc) {
- i915_gem_object_set_page_gfp_mask (obj,
- i915_gem_object_get_page_gfp_mask (obj) & ~__GFP_NORETRY);
- }
+ gfp = i915_gem_object_get_page_gfp_mask(obj);
+ if (! retry_alloc)
+ i915_gem_object_set_page_gfp_mask (obj, gfp | __GFP_NORETRY | __GFP_NOWARN);
ret = i915_gem_object_get_pages(obj);
- if (retry_alloc) {
- i915_gem_object_set_page_gfp_mask (obj,
- i915_gem_object_get_page_gfp_mask (obj) | __GFP_NORETRY);
- }
+ i915_gem_object_set_page_gfp_mask (obj, gfp);
+
if (ret) {
drm_mm_put_block(obj_priv->gtt_space);
obj_priv->gtt_space = NULL;
--
1.6.6
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 11:14 ` [PATCH] drm/i915: Selectively enable self-reclaim Chris Wilson
@ 2010-01-27 11:20 ` Pekka Enberg
2010-01-27 11:30 ` Michael Reinelt
2010-01-28 3:15 ` Michael Reinelt
2010-01-27 11:50 ` KOSAKI Motohiro
2010-01-27 12:16 ` Linus Torvalds
2 siblings, 2 replies; 52+ messages in thread
From: Pekka Enberg @ 2010-01-27 11:20 UTC (permalink / raw)
To: Chris Wilson
Cc: Linus Torvalds, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
Chris Wilson kirjoitti:
> Having missed the ENOMEM return via i915_gem_fault(), there are probably
> other paths that I also missed. By not enabling NORETRY by default these
> paths can run the shrinker and take memory from the system (but not from
> our own inactive lists because our shrinker can not run whilst we hold
> the struct mutex) and this may allow the system to survive a little longer
> whilst our drivers consume all available memory.
>
> References:
> OOM killer unexpectedly called with kernel 2.6.32
> http://bugzilla.kernel.org/show_bug.cgi?id=14933
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: stable@kernel.org
Roman, can you give this patch a spin?
> ---
> drivers/gpu/drm/drm_gem.c | 13 -------------
> drivers/gpu/drm/i915/i915_gem.c | 22 ++++++++++------------
> 2 files changed, 10 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index e9dbb48..8bf3770 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
> if (IS_ERR(obj->filp))
> goto free;
>
> - /* Basically we want to disable the OOM killer and handle ENOMEM
> - * ourselves by sacrificing pages from cached buffers.
> - * XXX shmem_file_[gs]et_gfp_mask()
> - */
> - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
> - GFP_HIGHUSER |
> - __GFP_COLD |
> - __GFP_FS |
> - __GFP_RECLAIMABLE |
> - __GFP_NORETRY |
> - __GFP_NOWARN |
> - __GFP_NOMEMALLOC);
> -
> kref_init(&obj->refcount);
> kref_init(&obj->handlecount);
> obj->size = size;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 28b8f03..1ef5b54 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -336,25 +336,25 @@ i915_gem_object_set_page_gfp_mask (struct drm_gem_object *obj, gfp_t gfp)
> static int
> i915_gem_object_get_pages_or_evict(struct drm_gem_object *obj)
> {
> + gfp_t gfp;
> int ret;
>
> + gfp = i915_gem_object_get_page_gfp_mask(obj);
> + i915_gem_object_set_page_gfp_mask(obj, gfp | __GFP_NORETRY | __GFP_NOWARN);
> ret = i915_gem_object_get_pages(obj);
> + i915_gem_object_set_page_gfp_mask (obj, gfp);
>
> /* If we've insufficient memory to map in the pages, attempt
> * to make some space by throwing out some old buffers.
> */
> if (ret == -ENOMEM) {
> struct drm_device *dev = obj->dev;
> - gfp_t gfp;
>
> ret = i915_gem_evict_something(dev, obj->size);
> if (ret)
> return ret;
>
> - gfp = i915_gem_object_get_page_gfp_mask(obj);
> - i915_gem_object_set_page_gfp_mask(obj, gfp & ~__GFP_NORETRY);
> ret = i915_gem_object_get_pages(obj);
> - i915_gem_object_set_page_gfp_mask (obj, gfp);
> }
>
> return ret;
> @@ -2580,6 +2580,7 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
> struct drm_i915_gem_object *obj_priv = obj->driver_private;
> struct drm_mm_node *free_space;
> bool retry_alloc = false;
> + gfp_t gfp;
> int ret;
>
> if (obj_priv->madv != I915_MADV_WILLNEED) {
> @@ -2623,15 +2624,12 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
> DRM_INFO("Binding object of size %zd at 0x%08x\n",
> obj->size, obj_priv->gtt_offset);
> #endif
> - if (retry_alloc) {
> - i915_gem_object_set_page_gfp_mask (obj,
> - i915_gem_object_get_page_gfp_mask (obj) & ~__GFP_NORETRY);
> - }
> + gfp = i915_gem_object_get_page_gfp_mask(obj);
> + if (! retry_alloc)
> + i915_gem_object_set_page_gfp_mask (obj, gfp | __GFP_NORETRY | __GFP_NOWARN);
> ret = i915_gem_object_get_pages(obj);
> - if (retry_alloc) {
> - i915_gem_object_set_page_gfp_mask (obj,
> - i915_gem_object_get_page_gfp_mask (obj) | __GFP_NORETRY);
> - }
> + i915_gem_object_set_page_gfp_mask (obj, gfp);
> +
> if (ret) {
> drm_mm_put_block(obj_priv->gtt_space);
> obj_priv->gtt_space = NULL;
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 11:20 ` Pekka Enberg
@ 2010-01-27 11:30 ` Michael Reinelt
2010-01-28 3:15 ` Michael Reinelt
1 sibling, 0 replies; 52+ messages in thread
From: Michael Reinelt @ 2010-01-27 11:30 UTC (permalink / raw)
To: Pekka Enberg
Cc: Chris Wilson, Linus Torvalds, Roman Jarosz, A Rojas, A. Boulan,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
Pekka Enberg schrieb:
> Chris Wilson kirjoitti:
>> Having missed the ENOMEM return via i915_gem_fault(), there are probably
>> other paths that I also missed. By not enabling NORETRY by default these
>> paths can run the shrinker and take memory from the system (but not from
>> our own inactive lists because our shrinker can not run whilst we hold
>> the struct mutex) and this may allow the system to survive a little
>> longer
>> whilst our drivers consume all available memory.
>>
>> References:
>> OOM killer unexpectedly called with kernel 2.6.32
>> http://bugzilla.kernel.org/show_bug.cgi?id=14933
>>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
>> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: stable@kernel.org
>
> Roman, can you give this patch a spin?
I'm willing to test it, too (I can easily reproduce the problem), but I don't use (and know nothing about) git. Is there
a way for me to test it?
--
Michael Reinelt <michael@reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 11:14 ` [PATCH] drm/i915: Selectively enable self-reclaim Chris Wilson
2010-01-27 11:20 ` Pekka Enberg
@ 2010-01-27 11:50 ` KOSAKI Motohiro
2010-01-27 12:16 ` Linus Torvalds
2 siblings, 0 replies; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-01-27 11:50 UTC (permalink / raw)
To: Chris Wilson
Cc: Linus Torvalds, Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan,
michael, jcnengel, rientjes, earny, linux-kernel, intel-gfx,
Hugh Dickins, Jesse Barnes, Eric Anholt, stable
2010/1/27 Chris Wilson <chris@chris-wilson.co.uk>:
> Having missed the ENOMEM return via i915_gem_fault(), there are probably
> other paths that I also missed. By not enabling NORETRY by default these
> paths can run the shrinker and take memory from the system (but not from
> our own inactive lists because our shrinker can not run whilst we hold
> the struct mutex) and this may allow the system to survive a little longer
> whilst our drivers consume all available memory.
>
> References:
> OOM killer unexpectedly called with kernel 2.6.32
> http://bugzilla.kernel.org/show_bug.cgi?id=14933
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: stable@kernel.org
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 11:14 ` [PATCH] drm/i915: Selectively enable self-reclaim Chris Wilson
2010-01-27 11:20 ` Pekka Enberg
2010-01-27 11:50 ` KOSAKI Motohiro
@ 2010-01-27 12:16 ` Linus Torvalds
2010-01-27 12:28 ` Linus Torvalds
2010-01-27 15:25 ` Chris Wilson
2 siblings, 2 replies; 52+ messages in thread
From: Linus Torvalds @ 2010-01-27 12:16 UTC (permalink / raw)
To: Chris Wilson
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Wed, 27 Jan 2010, Chris Wilson wrote:
>
> + gfp = i915_gem_object_get_page_gfp_mask(obj);
> + i915_gem_object_set_page_gfp_mask(obj, gfp | __GFP_NORETRY | __GFP_NOWARN);
> ret = i915_gem_object_get_pages(obj);
> + i915_gem_object_set_page_gfp_mask (obj, gfp);
This is just all still totally and utterly broken.
There is no possible reason why something like drm should _ever_ play with
the mapping gfp-mask. The fact that you guys do means that something is
seriously wrong.
Setting the mapping gfp mask like that is totally wrong. Yes, it looks
like you take the 'struct_mutex' lock, but I don't think the page fault
does that, does it? So the locking in no way protects other uses of that
mapping gfp mask.
Guys, this is just not acceptable. Playing games like this with obvious
crap code is not the way to fix any problems what-so-ever. Even if the
code happens to work, just a quick look at it clearly says "oh, that's
ugly".
Just pass in the GFP mask to i915_gem_object_get_pages() instead, and stop
making up these sh*tty idiotic interfaces.
The whole "mapping_set_gfp_mask()" function that you use is meant to
INITIALIZE a mapping when it is created. It's simply not safe at run-time.
It never was, and it never will be.
So get rid of that whole i915_gem_object_set_page_gfp_mask() function -
any user is by definition pure and utter crap.
Now, if you want to pass the gfp mask to the allocator directly (and
judging by the code, that's _exactly_ what you want to do), then you don't
want to use the read_mapping_page() helper function. That is very much
designed to take the mappign GFP.
You can do your own version, something like this:
struct page *i915_gem_get_page(struct address_space *mapping, pgoff_t index)
{
for (;;) {
int err;
struct page *page;
page = find_get_page(mapping, index);
if (page)
return page;
page = __page_cache_alloc(gfpmask | __GFP_ZERO);
if (!page)
return ERR_PTR(-ENOMEM);
/* Zero-page is already uptodate */
__SetPageUptodate(page);
err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
if (err) {
page_cache_release(page);
if (err == -EEXIST)
continue;
return ERR_PTR(err);
}
return page;
}
}
and now you have a way to allocate cleared pages into that mapping with a
GFP that you control.
We could even make it a generic helper function if we just did that whole
"mapping->a_ops->readpage()" dance or whatever and add the required async
waiting etc. But I think gem just basically wants a zero-initialized
mapping, no?
THE ABOVE IS TOTALLY UNTESTED. I wrote it in the mail-reader. It hasn't
seen a compiler, and I didn't actually check that gem really just wants
pages that are initialized to zero (aka "simle_readpage"), so what the
heck do I know. My point is that something like the above should work in
the sense that it avoids the whole "play games with setting a global
gfpmask" thing, and keeps the gfpmask local to the execution.
Oh, and if you actually use shmem/tmpfs and can swap your pages out, then
you do need to do the whole readpage() thing. It gets more complex then
(you can't just mark things up-to-date, you need to lock the page, check
PageUptodate() and friends etc etc).
I didn't check where that 'mapping' thing gets initialized.
Another alternative would be to keep the current i915_gem logic, but pass
the gfp down all the way to read_cache_page(), rather than take it from
the mapping. Then we'd make the 'read_mapping_page()' function look up the
gfp (so users of 'read_mapping_page()' would get the old behavior, but we
could call read_cache_page() with a gfpmask that is different from the
mapping->gfpmask).
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 12:16 ` Linus Torvalds
@ 2010-01-27 12:28 ` Linus Torvalds
2010-01-27 15:25 ` Chris Wilson
1 sibling, 0 replies; 52+ messages in thread
From: Linus Torvalds @ 2010-01-27 12:28 UTC (permalink / raw)
To: Chris Wilson
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Wed, 27 Jan 2010, Linus Torvalds wrote:
>
> Setting the mapping gfp mask like that is totally wrong. Yes, it looks
> like you take the 'struct_mutex' lock, but I don't think the page fault
> does that, does it? So the locking in no way protects other uses of that
> mapping gfp mask.
Actually, it looks like the gem_fault code _does_ take the lock. So I
guess it's technically correct. If still really really ugly.
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 12:16 ` Linus Torvalds
2010-01-27 12:28 ` Linus Torvalds
@ 2010-01-27 15:25 ` Chris Wilson
2010-01-27 16:09 ` Linus Torvalds
1 sibling, 1 reply; 52+ messages in thread
From: Chris Wilson @ 2010-01-27 15:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx, Chris Wilson,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
Having missed the ENOMEM return via i915_gem_fault(), there are probably
other paths that I also missed. By not enabling NORETRY by default these
paths can run the shrinker and take memory from the system (but not from
our own inactive lists because our shrinker can not run whilst we hold
the struct mutex) and this may allow the system to survive a little longer
whilst our drivers consume all available memory.
References:
OOM killer unexpectedly called with kernel 2.6.32
http://bugzilla.kernel.org/show_bug.cgi?id=14933
v2: Pass gfp into page mapping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
---
drivers/gpu/drm/drm_gem.c | 13 ----
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 112 +++++++++++++++++++++++------------
4 files changed, 77 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e9dbb48..8bf3770 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
if (IS_ERR(obj->filp))
goto free;
- /* Basically we want to disable the OOM killer and handle ENOMEM
- * ourselves by sacrificing pages from cached buffers.
- * XXX shmem_file_[gs]et_gfp_mask()
- */
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
- GFP_HIGHUSER |
- __GFP_COLD |
- __GFP_FS |
- __GFP_RECLAIMABLE |
- __GFP_NORETRY |
- __GFP_NOWARN |
- __GFP_NOMEMALLOC);
-
kref_init(&obj->refcount);
kref_init(&obj->handlecount);
obj->size = size;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 9c9998c..a894ade 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -290,7 +290,7 @@ static int i915_batchbuffer_info(struct seq_file *m, void *data)
list_for_each_entry(obj_priv, &dev_priv->mm.active_list, list) {
obj = obj_priv->obj;
if (obj->read_domains & I915_GEM_DOMAIN_COMMAND) {
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret) {
DRM_ERROR("Failed to get pages: %d\n", ret);
spin_unlock(&dev_priv->mm.active_list_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c16694..aaf934d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -872,7 +872,7 @@ int i915_gem_attach_phys_object(struct drm_device *dev,
void i915_gem_detach_phys_object(struct drm_device *dev,
struct drm_gem_object *obj);
void i915_gem_free_all_phys_object(struct drm_device *dev);
-int i915_gem_object_get_pages(struct drm_gem_object *obj);
+int i915_gem_object_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
void i915_gem_object_put_pages(struct drm_gem_object *obj);
void i915_gem_release(struct drm_device * dev, struct drm_file *file_priv);
void i915_gem_object_flush_write_domain(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0c67924..f74a099 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -277,7 +277,7 @@ i915_gem_shmem_pread_fast(struct drm_device *dev, struct drm_gem_object *obj,
mutex_lock(&dev->struct_mutex);
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret != 0)
goto fail_unlock;
@@ -321,40 +321,24 @@ fail_unlock:
return ret;
}
-static inline gfp_t
-i915_gem_object_get_page_gfp_mask (struct drm_gem_object *obj)
-{
- return mapping_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping);
-}
-
-static inline void
-i915_gem_object_set_page_gfp_mask (struct drm_gem_object *obj, gfp_t gfp)
-{
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping, gfp);
-}
-
static int
i915_gem_object_get_pages_or_evict(struct drm_gem_object *obj)
{
int ret;
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, __GFP_NORETRY | __GFP_NOWARN);
/* If we've insufficient memory to map in the pages, attempt
* to make some space by throwing out some old buffers.
*/
if (ret == -ENOMEM) {
struct drm_device *dev = obj->dev;
- gfp_t gfp;
ret = i915_gem_evict_something(dev, obj->size);
if (ret)
return ret;
- gfp = i915_gem_object_get_page_gfp_mask(obj);
- i915_gem_object_set_page_gfp_mask(obj, gfp & ~__GFP_NORETRY);
- ret = i915_gem_object_get_pages(obj);
- i915_gem_object_set_page_gfp_mask (obj, gfp);
+ ret = i915_gem_object_get_pages(obj, 0);
}
return ret;
@@ -790,7 +774,7 @@ i915_gem_shmem_pwrite_fast(struct drm_device *dev, struct drm_gem_object *obj,
mutex_lock(&dev->struct_mutex);
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret != 0)
goto fail_unlock;
@@ -2229,8 +2213,70 @@ i915_gem_evict_something(struct drm_device *dev, int min_size)
}
}
+/* like read_mapping_page(), but takes a gfp mask for the allocation */
+static struct page *
+i915_gem_read_cache_page(struct address_space *mapping,
+ pgoff_t index,
+ gfp_t gfpmask)
+{
+ struct page *page;
+ int err;
+
+retry:
+ page = find_get_page(mapping, index);
+ if (!page) {
+ page = __page_cache_alloc(mapping_gfp_mask(mapping) | __GFP_COLD | gfpmask);
+ if (!page)
+ return ERR_PTR(-ENOMEM);
+
+ err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
+ if (unlikely(err)) {
+ page_cache_release(page);
+ if (err == -EEXIST)
+ goto retry;
+
+ /* Presumably ENOMEM for radix tree node */
+ return ERR_PTR(err);
+ }
+ } else {
+ if (PageUptodate(page)) {
+ mark_page_accessed(page);
+ return page;
+ }
+
+ lock_page(page);
+ if (!page->mapping) {
+ unlock_page(page);
+ page_cache_release(page);
+ goto retry;
+ }
+
+ if (PageUptodate(page)) {
+ mark_page_accessed(page);
+ unlock_page(page);
+ return page;
+ }
+ }
+
+ err = mapping->a_ops->readpage(NULL, page);
+ if (err < 0) {
+ unlock_page(page);
+ page_cache_release(page);
+ return ERR_PTR(err);
+ }
+ mark_page_accessed(page);
+ wait_on_page_locked(page);
+ if (!PageUptodate(page)) {
+ page_cache_release(page);
+ return ERR_PTR(-EIO);
+ }
+
+ return page;
+}
+
int
-i915_gem_object_get_pages(struct drm_gem_object *obj)
+i915_gem_object_get_pages(struct drm_gem_object *obj,
+ gfp_t gfpmask)
{
struct drm_i915_gem_object *obj_priv = obj->driver_private;
int page_count, i;
@@ -2256,7 +2302,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj)
inode = obj->filp->f_path.dentry->d_inode;
mapping = inode->i_mapping;
for (i = 0; i < page_count; i++) {
- page = read_mapping_page(mapping, i, NULL);
+ page = i915_gem_read_cache_page(mapping, i, gfpmask);
if (IS_ERR(page)) {
ret = PTR_ERR(page);
i915_gem_object_put_pages(obj);
@@ -2579,7 +2625,7 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
drm_i915_private_t *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj_priv = obj->driver_private;
struct drm_mm_node *free_space;
- bool retry_alloc = false;
+ gfp_t gfpmask = __GFP_NORETRY | __GFP_NOWARN;
int ret;
if (obj_priv->madv != I915_MADV_WILLNEED) {
@@ -2623,15 +2669,7 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
DRM_INFO("Binding object of size %zd at 0x%08x\n",
obj->size, obj_priv->gtt_offset);
#endif
- if (retry_alloc) {
- i915_gem_object_set_page_gfp_mask (obj,
- i915_gem_object_get_page_gfp_mask (obj) & ~__GFP_NORETRY);
- }
- ret = i915_gem_object_get_pages(obj);
- if (retry_alloc) {
- i915_gem_object_set_page_gfp_mask (obj,
- i915_gem_object_get_page_gfp_mask (obj) | __GFP_NORETRY);
- }
+ ret = i915_gem_object_get_pages(obj, gfpmask);
if (ret) {
drm_mm_put_block(obj_priv->gtt_space);
obj_priv->gtt_space = NULL;
@@ -2641,9 +2679,9 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
ret = i915_gem_evict_something(dev, obj->size);
if (ret) {
/* now try to shrink everyone else */
- if (! retry_alloc) {
- retry_alloc = true;
- goto search_free;
+ if (gfpmask) {
+ gfpmask = 0;
+ goto search_free;
}
return ret;
@@ -4946,7 +4984,7 @@ void i915_gem_detach_phys_object(struct drm_device *dev,
if (!obj_priv->phys_obj)
return;
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret)
goto out;
@@ -5004,7 +5042,7 @@ i915_gem_attach_phys_object(struct drm_device *dev,
obj_priv->phys_obj = dev_priv->mm.phys_objs[id - 1];
obj_priv->phys_obj->cur_obj = obj;
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret) {
DRM_ERROR("failed to get page list\n");
goto out;
--
1.6.6
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 15:25 ` Chris Wilson
@ 2010-01-27 16:09 ` Linus Torvalds
2010-01-27 17:14 ` Chris Wilson
0 siblings, 1 reply; 52+ messages in thread
From: Linus Torvalds @ 2010-01-27 16:09 UTC (permalink / raw)
To: Chris Wilson
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Wed, 27 Jan 2010, Chris Wilson wrote:
>
> v2: Pass gfp into page mapping.
Ahh, you did need the whole complexity of ->readpage?
Ok, in that case, can you test if this works for you?
It adds a 'read_cache_page_gfp()' function, which is a simplified form of
read_cache_page() (no need to pass in filler/data, it uses the default
values, like read_mapping_page() does), but allows setting gfp explicitly.
Untested, but if you test it and it works for you, then I think it's a
reasonable addition. There might be other cases where some users prefer
certain flags.
The actual new function is just a single line, the real patch is changing
(and splitting up) the helper functions a bit so that all the variations
on read_cache_page_*() can all be trivial.
Linus
---
include/linux/pagemap.h | 2 +
mm/filemap.c | 100 ++++++++++++++++++++++++++++++++---------------
2 files changed, 70 insertions(+), 32 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index ed5d750..3c62ed4 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -253,6 +253,8 @@ extern struct page * read_cache_page_async(struct address_space *mapping,
extern struct page * read_cache_page(struct address_space *mapping,
pgoff_t index, filler_t *filler,
void *data);
+extern struct page * read_cache_page_gfp(struct address_space *mapping,
+ pgoff_t index, gfp_t gfp_mask);
extern int read_cache_pages(struct address_space *mapping,
struct list_head *pages, filler_t *filler, void *data);
diff --git a/mm/filemap.c b/mm/filemap.c
index 96ac6b0..e373692 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1634,14 +1634,15 @@ EXPORT_SYMBOL(generic_file_readonly_mmap);
static struct page *__read_cache_page(struct address_space *mapping,
pgoff_t index,
int (*filler)(void *,struct page*),
- void *data)
+ void *data,
+ gfp_t gfp)
{
struct page *page;
int err;
repeat:
page = find_get_page(mapping, index);
if (!page) {
- page = page_cache_alloc_cold(mapping);
+ page = __page_cache_alloc(gfp | __GFP_COLD);
if (!page)
return ERR_PTR(-ENOMEM);
err = add_to_page_cache_lru(page, mapping, index, GFP_KERNEL);
@@ -1661,31 +1662,18 @@ repeat:
return page;
}
-/**
- * read_cache_page_async - read into page cache, fill it if needed
- * @mapping: the page's address_space
- * @index: the page index
- * @filler: function to perform the read
- * @data: destination for read data
- *
- * Same as read_cache_page, but don't wait for page to become unlocked
- * after submitting it to the filler.
- *
- * Read into the page cache. If a page already exists, and PageUptodate() is
- * not set, try to fill the page but don't wait for it to become unlocked.
- *
- * If the page does not get brought uptodate, return -EIO.
- */
-struct page *read_cache_page_async(struct address_space *mapping,
+static struct page *do_read_cache_page(struct address_space *mapping,
pgoff_t index,
int (*filler)(void *,struct page*),
- void *data)
+ void *data,
+ gfp_t gfp)
+
{
struct page *page;
int err;
retry:
- page = __read_cache_page(mapping, index, filler, data);
+ page = __read_cache_page(mapping, index, filler, data, gfp);
if (IS_ERR(page))
return page;
if (PageUptodate(page))
@@ -1710,8 +1698,67 @@ out:
mark_page_accessed(page);
return page;
}
+
+/**
+ * read_cache_page_async - read into page cache, fill it if needed
+ * @mapping: the page's address_space
+ * @index: the page index
+ * @filler: function to perform the read
+ * @data: destination for read data
+ *
+ * Same as read_cache_page, but don't wait for page to become unlocked
+ * after submitting it to the filler.
+ *
+ * Read into the page cache. If a page already exists, and PageUptodate() is
+ * not set, try to fill the page but don't wait for it to become unlocked.
+ *
+ * If the page does not get brought uptodate, return -EIO.
+ */
+struct page *read_cache_page_async(struct address_space *mapping,
+ pgoff_t index,
+ int (*filler)(void *,struct page*),
+ void *data)
+{
+ return do_read_cache_page(mapping, index, filler, data, mapping_gfp_mask(mapping));
+}
EXPORT_SYMBOL(read_cache_page_async);
+static struct page *wait_on_page_read(struct page *page)
+{
+ if (!IS_ERR(page)) {
+ wait_on_page_locked(page);
+ if (!PageUptodate(page)) {
+ page_cache_release(page);
+ page = ERR_PTR(-EIO);
+ }
+ }
+ return page;
+}
+
+/**
+ * read_cache_page_gfp - read into page cache, using specified page allocation flags.
+ * @mapping: the page's address_space
+ * @index: the page index
+ * @gfp: the page allocator flags to use if allocating
+ *
+ * This is the same as "read_mapping_page(mapping, index, NULL)", but with
+ * any new page allocations done using the specified allocation flags. Note
+ * that the Radix tree operations will still use GFP_KERNEL, so you can't
+ * expect to do this atomically or anything like that - but you can pass in
+ * other page requirements.
+ *
+ * If the page does not get brought uptodate, return -EIO.
+ */
+struct page *read_cache_page_gfp(struct address_space *mapping,
+ pgoff_t index,
+ gfp_t gfp)
+{
+ filler_t *filler = (filler_t *)mapping->a_ops->readpage;
+
+ return wait_on_page_read(do_read_cache_page(mapping, index, filler, NULL, gfp));
+}
+EXPORT_SYMBOL(read_cache_page_gfp);
+
/**
* read_cache_page - read into page cache, fill it if needed
* @mapping: the page's address_space
@@ -1729,18 +1776,7 @@ struct page *read_cache_page(struct address_space *mapping,
int (*filler)(void *,struct page*),
void *data)
{
- struct page *page;
-
- page = read_cache_page_async(mapping, index, filler, data);
- if (IS_ERR(page))
- goto out;
- wait_on_page_locked(page);
- if (!PageUptodate(page)) {
- page_cache_release(page);
- page = ERR_PTR(-EIO);
- }
- out:
- return page;
+ return wait_on_page_read(read_cache_page_async(mapping, index, filler, data));
}
EXPORT_SYMBOL(read_cache_page);
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 16:09 ` Linus Torvalds
@ 2010-01-27 17:14 ` Chris Wilson
2010-01-27 17:19 ` Linus Torvalds
2010-01-28 6:37 ` Willy Tarreau
0 siblings, 2 replies; 52+ messages in thread
From: Chris Wilson @ 2010-01-27 17:14 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Wed, 27 Jan 2010 08:09:55 -0800 (PST), Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 27 Jan 2010, Chris Wilson wrote:
> >
> > v2: Pass gfp into page mapping.
>
> Ahh, you did need the whole complexity of ->readpage?
>
> Ok, in that case, can you test if this works for you?
Yes, it survives a short torture test that leaks lots of bo objects from
X. Obviously this patch depends upon the new interface.
---
>From 3f63bea00af2027d668055bc4124f6a1ae28b95b Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed, 27 Jan 2010 13:36:32 +0000
Subject: [PATCH] drm/i915: Selectively enable self-reclaim
Having missed the ENOMEM return via i915_gem_fault(), there are probably
other paths that I also missed. By not enabling NORETRY by default these
paths can run the shrinker and take memory from the system (but not from
our own inactive lists because our shrinker can not run whilst we hold
the struct mutex) and this may allow the system to survive a little longer
whilst our drivers consume all available memory.
References:
OOM killer unexpectedly called with kernel 2.6.32
http://bugzilla.kernel.org/show_bug.cgi?id=14933
v2: Pass gfp into page mapping.
v3: Use new read_cache_page_gfp() instead of open-coding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
---
drivers/gpu/drm/drm_gem.c | 13 --------
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 54 +++++++++++------------------------
4 files changed, 19 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e9dbb48..8bf3770 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
if (IS_ERR(obj->filp))
goto free;
- /* Basically we want to disable the OOM killer and handle ENOMEM
- * ourselves by sacrificing pages from cached buffers.
- * XXX shmem_file_[gs]et_gfp_mask()
- */
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
- GFP_HIGHUSER |
- __GFP_COLD |
- __GFP_FS |
- __GFP_RECLAIMABLE |
- __GFP_NORETRY |
- __GFP_NOWARN |
- __GFP_NOMEMALLOC);
-
kref_init(&obj->refcount);
kref_init(&obj->handlecount);
obj->size = size;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index 9c9998c..a894ade 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -290,7 +290,7 @@ static int i915_batchbuffer_info(struct seq_file *m, void *data)
list_for_each_entry(obj_priv, &dev_priv->mm.active_list, list) {
obj = obj_priv->obj;
if (obj->read_domains & I915_GEM_DOMAIN_COMMAND) {
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret) {
DRM_ERROR("Failed to get pages: %d\n", ret);
spin_unlock(&dev_priv->mm.active_list_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c16694..aaf934d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -872,7 +872,7 @@ int i915_gem_attach_phys_object(struct drm_device *dev,
void i915_gem_detach_phys_object(struct drm_device *dev,
struct drm_gem_object *obj);
void i915_gem_free_all_phys_object(struct drm_device *dev);
-int i915_gem_object_get_pages(struct drm_gem_object *obj);
+int i915_gem_object_get_pages(struct drm_gem_object *obj, gfp_t gfpmask);
void i915_gem_object_put_pages(struct drm_gem_object *obj);
void i915_gem_release(struct drm_device * dev, struct drm_file *file_priv);
void i915_gem_object_flush_write_domain(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0c67924..dda787a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -277,7 +277,7 @@ i915_gem_shmem_pread_fast(struct drm_device *dev, struct drm_gem_object *obj,
mutex_lock(&dev->struct_mutex);
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret != 0)
goto fail_unlock;
@@ -321,40 +321,24 @@ fail_unlock:
return ret;
}
-static inline gfp_t
-i915_gem_object_get_page_gfp_mask (struct drm_gem_object *obj)
-{
- return mapping_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping);
-}
-
-static inline void
-i915_gem_object_set_page_gfp_mask (struct drm_gem_object *obj, gfp_t gfp)
-{
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping, gfp);
-}
-
static int
i915_gem_object_get_pages_or_evict(struct drm_gem_object *obj)
{
int ret;
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, __GFP_NORETRY | __GFP_NOWARN);
/* If we've insufficient memory to map in the pages, attempt
* to make some space by throwing out some old buffers.
*/
if (ret == -ENOMEM) {
struct drm_device *dev = obj->dev;
- gfp_t gfp;
ret = i915_gem_evict_something(dev, obj->size);
if (ret)
return ret;
- gfp = i915_gem_object_get_page_gfp_mask(obj);
- i915_gem_object_set_page_gfp_mask(obj, gfp & ~__GFP_NORETRY);
- ret = i915_gem_object_get_pages(obj);
- i915_gem_object_set_page_gfp_mask (obj, gfp);
+ ret = i915_gem_object_get_pages(obj, 0);
}
return ret;
@@ -790,7 +774,7 @@ i915_gem_shmem_pwrite_fast(struct drm_device *dev, struct drm_gem_object *obj,
mutex_lock(&dev->struct_mutex);
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret != 0)
goto fail_unlock;
@@ -2230,7 +2214,8 @@ i915_gem_evict_something(struct drm_device *dev, int min_size)
}
int
-i915_gem_object_get_pages(struct drm_gem_object *obj)
+i915_gem_object_get_pages(struct drm_gem_object *obj,
+ gfp_t gfpmask)
{
struct drm_i915_gem_object *obj_priv = obj->driver_private;
int page_count, i;
@@ -2256,7 +2241,10 @@ i915_gem_object_get_pages(struct drm_gem_object *obj)
inode = obj->filp->f_path.dentry->d_inode;
mapping = inode->i_mapping;
for (i = 0; i < page_count; i++) {
- page = read_mapping_page(mapping, i, NULL);
+ page = read_cache_page_gfp(mapping, i,
+ mapping_gfp_mask (mapping) |
+ __GFP_COLD |
+ gfpmask);
if (IS_ERR(page)) {
ret = PTR_ERR(page);
i915_gem_object_put_pages(obj);
@@ -2579,7 +2567,7 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
drm_i915_private_t *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj_priv = obj->driver_private;
struct drm_mm_node *free_space;
- bool retry_alloc = false;
+ gfp_t gfpmask = __GFP_NORETRY | __GFP_NOWARN;
int ret;
if (obj_priv->madv != I915_MADV_WILLNEED) {
@@ -2623,15 +2611,7 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
DRM_INFO("Binding object of size %zd at 0x%08x\n",
obj->size, obj_priv->gtt_offset);
#endif
- if (retry_alloc) {
- i915_gem_object_set_page_gfp_mask (obj,
- i915_gem_object_get_page_gfp_mask (obj) & ~__GFP_NORETRY);
- }
- ret = i915_gem_object_get_pages(obj);
- if (retry_alloc) {
- i915_gem_object_set_page_gfp_mask (obj,
- i915_gem_object_get_page_gfp_mask (obj) | __GFP_NORETRY);
- }
+ ret = i915_gem_object_get_pages(obj, gfpmask);
if (ret) {
drm_mm_put_block(obj_priv->gtt_space);
obj_priv->gtt_space = NULL;
@@ -2641,9 +2621,9 @@ i915_gem_object_bind_to_gtt(struct drm_gem_object *obj, unsigned alignment)
ret = i915_gem_evict_something(dev, obj->size);
if (ret) {
/* now try to shrink everyone else */
- if (! retry_alloc) {
- retry_alloc = true;
- goto search_free;
+ if (gfpmask) {
+ gfpmask = 0;
+ goto search_free;
}
return ret;
@@ -4946,7 +4926,7 @@ void i915_gem_detach_phys_object(struct drm_device *dev,
if (!obj_priv->phys_obj)
return;
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret)
goto out;
@@ -5004,7 +4984,7 @@ i915_gem_attach_phys_object(struct drm_device *dev,
obj_priv->phys_obj = dev_priv->mm.phys_objs[id - 1];
obj_priv->phys_obj->cur_obj = obj;
- ret = i915_gem_object_get_pages(obj);
+ ret = i915_gem_object_get_pages(obj, 0);
if (ret) {
DRM_ERROR("failed to get page list\n");
goto out;
--
1.6.6
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 17:14 ` Chris Wilson
@ 2010-01-27 17:19 ` Linus Torvalds
2010-01-27 21:03 ` Roman Jarosz
2010-06-30 6:54 ` [Intel-gfx] " Dave Airlie
2010-01-28 6:37 ` Willy Tarreau
1 sibling, 2 replies; 52+ messages in thread
From: Linus Torvalds @ 2010-01-27 17:19 UTC (permalink / raw)
To: Chris Wilson
Cc: Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan, michael,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Wed, 27 Jan 2010, Chris Wilson wrote:
>
> Yes, it survives a short torture test that leaks lots of bo objects from
> X. Obviously this patch depends upon the new interface.
All right. I'll apply my patch, since i'd rather have any half-way complex
logic for handling mappings in the generic mm code. And then I'll apply
yours, because now I can look at it without wanting to dig my eyes out.
Thanks,
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 17:19 ` Linus Torvalds
@ 2010-01-27 21:03 ` Roman Jarosz
2010-06-30 6:54 ` [Intel-gfx] " Dave Airlie
1 sibling, 0 replies; 52+ messages in thread
From: Roman Jarosz @ 2010-01-27 21:03 UTC (permalink / raw)
To: Linus Torvalds, Chris Wilson
Cc: Pekka Enberg, A Rojas, A. Boulan, michael, jcnengel, rientjes,
earny, linux-kernel, intel-gfx, KOSAKI Motohiro, Hugh Dickins,
Jesse Barnes, Eric Anholt, stable
On Wed, 27 Jan 2010 18:19:50 +0100, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 27 Jan 2010, Chris Wilson wrote:
>>
>> Yes, it survives a short torture test that leaks lots of bo objects from
>> X. Obviously this patch depends upon the new interface.
>
> All right. I'll apply my patch, since i'd rather have any half-way
> complex
> logic for handling mappings in the generic mm code. And then I'll apply
> yours, because now I can look at it without wanting to dig my eyes out.
>
> Thanks,
>
> Linus
I will test it tomorrow in the evening.
Regards
Roman
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 11:20 ` Pekka Enberg
2010-01-27 11:30 ` Michael Reinelt
@ 2010-01-28 3:15 ` Michael Reinelt
2010-01-28 18:21 ` Roman Jarosz
1 sibling, 1 reply; 52+ messages in thread
From: Michael Reinelt @ 2010-01-28 3:15 UTC (permalink / raw)
To: Pekka Enberg
Cc: Chris Wilson, Linus Torvalds, Roman Jarosz, A Rojas, A. Boulan,
jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
Pekka Enberg schrieb:
> Chris Wilson kirjoitti:
>> Having missed the ENOMEM return via i915_gem_fault(), there are probably
>> other paths that I also missed. By not enabling NORETRY by default these
>> paths can run the shrinker and take memory from the system (but not from
>> our own inactive lists because our shrinker can not run whilst we hold
>> the struct mutex) and this may allow the system to survive a little
>> longer
>> whilst our drivers consume all available memory.
>>
>> References:
>> OOM killer unexpectedly called with kernel 2.6.32
>> http://bugzilla.kernel.org/show_bug.cgi?id=14933
>>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
>> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: stable@kernel.org
>
> Roman, can you give this patch a spin?
Applied to 2.6.33-rc5, stress-test under heavy load, no problem so far. Looks fine!
>> ---
>> drivers/gpu/drm/drm_gem.c | 13 -------------
>> drivers/gpu/drm/i915/i915_gem.c | 22 ++++++++++------------
>> 2 files changed, 10 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> index e9dbb48..8bf3770 100644
>> --- a/drivers/gpu/drm/drm_gem.c
>> +++ b/drivers/gpu/drm/drm_gem.c
>> @@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev,
>> size_t size)
>> if (IS_ERR(obj->filp))
>> goto free;
>>
>> - /* Basically we want to disable the OOM killer and handle ENOMEM
>> - * ourselves by sacrificing pages from cached buffers.
>> - * XXX shmem_file_[gs]et_gfp_mask()
>> - */
>> - mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
>> - GFP_HIGHUSER |
>> - __GFP_COLD |
>> - __GFP_FS |
>> - __GFP_RECLAIMABLE |
>> - __GFP_NORETRY |
>> - __GFP_NOWARN |
>> - __GFP_NOMEMALLOC);
>> -
>> kref_init(&obj->refcount);
>> kref_init(&obj->handlecount);
>> obj->size = size;
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 28b8f03..1ef5b54 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -336,25 +336,25 @@ i915_gem_object_set_page_gfp_mask (struct
>> drm_gem_object *obj, gfp_t gfp)
>> static int
>> i915_gem_object_get_pages_or_evict(struct drm_gem_object *obj)
>> {
>> + gfp_t gfp;
>> int ret;
>>
>> + gfp = i915_gem_object_get_page_gfp_mask(obj);
>> + i915_gem_object_set_page_gfp_mask(obj, gfp | __GFP_NORETRY |
>> __GFP_NOWARN);
>> ret = i915_gem_object_get_pages(obj);
>> + i915_gem_object_set_page_gfp_mask (obj, gfp);
>>
>> /* If we've insufficient memory to map in the pages, attempt
>> * to make some space by throwing out some old buffers.
>> */
>> if (ret == -ENOMEM) {
>> struct drm_device *dev = obj->dev;
>> - gfp_t gfp;
>>
>> ret = i915_gem_evict_something(dev, obj->size);
>> if (ret)
>> return ret;
>>
>> - gfp = i915_gem_object_get_page_gfp_mask(obj);
>> - i915_gem_object_set_page_gfp_mask(obj, gfp & ~__GFP_NORETRY);
>> ret = i915_gem_object_get_pages(obj);
>> - i915_gem_object_set_page_gfp_mask (obj, gfp);
>> }
>>
>> return ret;
>> @@ -2580,6 +2580,7 @@ i915_gem_object_bind_to_gtt(struct
>> drm_gem_object *obj, unsigned alignment)
>> struct drm_i915_gem_object *obj_priv = obj->driver_private;
>> struct drm_mm_node *free_space;
>> bool retry_alloc = false;
>> + gfp_t gfp;
>> int ret;
>>
>> if (obj_priv->madv != I915_MADV_WILLNEED) {
>> @@ -2623,15 +2624,12 @@ i915_gem_object_bind_to_gtt(struct
>> drm_gem_object *obj, unsigned alignment)
>> DRM_INFO("Binding object of size %zd at 0x%08x\n",
>> obj->size, obj_priv->gtt_offset);
>> #endif
>> - if (retry_alloc) {
>> - i915_gem_object_set_page_gfp_mask (obj,
>> - i915_gem_object_get_page_gfp_mask (obj) &
>> ~__GFP_NORETRY);
>> - }
>> + gfp = i915_gem_object_get_page_gfp_mask(obj);
>> + if (! retry_alloc)
>> + i915_gem_object_set_page_gfp_mask (obj, gfp | __GFP_NORETRY |
>> __GFP_NOWARN);
>> ret = i915_gem_object_get_pages(obj);
>> - if (retry_alloc) {
>> - i915_gem_object_set_page_gfp_mask (obj,
>> - i915_gem_object_get_page_gfp_mask (obj) |
>> __GFP_NORETRY);
>> - }
>> + i915_gem_object_set_page_gfp_mask (obj, gfp);
>> +
>> if (ret) {
>> drm_mm_put_block(obj_priv->gtt_space);
>> obj_priv->gtt_space = NULL;
>
>
>
--
Michael Reinelt <michael@reinelt.co.at>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 17:14 ` Chris Wilson
2010-01-27 17:19 ` Linus Torvalds
@ 2010-01-28 6:37 ` Willy Tarreau
1 sibling, 0 replies; 52+ messages in thread
From: Willy Tarreau @ 2010-01-28 6:37 UTC (permalink / raw)
To: Chris Wilson
Cc: Linus Torvalds, Pekka Enberg, Roman Jarosz, A Rojas, A. Boulan,
michael, jcnengel, rientjes, earny, linux-kernel, intel-gfx,
KOSAKI Motohiro, Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Wed, Jan 27, 2010 at 05:14:41PM +0000, Chris Wilson wrote:
> On Wed, 27 Jan 2010 08:09:55 -0800 (PST), Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Wed, 27 Jan 2010, Chris Wilson wrote:
> > >
> > > v2: Pass gfp into page mapping.
> >
> > Ahh, you did need the whole complexity of ->readpage?
> >
> > Ok, in that case, can you test if this works for you?
>
> Yes, it survives a short torture test that leaks lots of bo objects from
> X. Obviously this patch depends upon the new interface.
So does this needs that previous patch is still valid for 2.6.32-stable ?
If so, you'll probably have to point it to Greg directly so that he has
no trouble backporting the new one.
Willy
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-28 3:15 ` Michael Reinelt
@ 2010-01-28 18:21 ` Roman Jarosz
0 siblings, 0 replies; 52+ messages in thread
From: Roman Jarosz @ 2010-01-28 18:21 UTC (permalink / raw)
To: Michael Reinelt, Pekka Enberg
Cc: Chris Wilson, Linus Torvalds, A Rojas, A. Boulan, jcnengel,
rientjes, earny, linux-kernel, intel-gfx, KOSAKI Motohiro,
Hugh Dickins, Jesse Barnes, Eric Anholt, stable
On Thu, 28 Jan 2010 04:15:00 +0100, Michael Reinelt
<michael@reinelt.co.at> wrote:
>
>
> Pekka Enberg schrieb:
>> Chris Wilson kirjoitti:
>>> Having missed the ENOMEM return via i915_gem_fault(), there are
>>> probably
>>> other paths that I also missed. By not enabling NORETRY by default
>>> these
>>> paths can run the shrinker and take memory from the system (but not
>>> from
>>> our own inactive lists because our shrinker can not run whilst we hold
>>> the struct mutex) and this may allow the system to survive a little
>>> longer
>>> whilst our drivers consume all available memory.
>>>
>>> References:
>>> OOM killer unexpectedly called with kernel 2.6.32
>>> http://bugzilla.kernel.org/show_bug.cgi?id=14933
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
>>> Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
>>> Cc: Eric Anholt <eric@anholt.net>
>>> Cc: stable@kernel.org
>>
>> Roman, can you give this patch a spin?
>
> Applied to 2.6.33-rc5, stress-test under heavy load, no problem so far.
> Looks fine!
Here it works too, thanks!
Roman
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-01-27 17:19 ` Linus Torvalds
2010-01-27 21:03 ` Roman Jarosz
@ 2010-06-30 6:54 ` Dave Airlie
2010-06-30 7:05 ` Chris Wilson
1 sibling, 1 reply; 52+ messages in thread
From: Dave Airlie @ 2010-06-30 6:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Wilson, earny, Roman Jarosz, intel-gfx, linux-kernel,
jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg, A Rojas,
KOSAKI Motohiro, rientjes, michael, stable
On Thu, Jan 28, 2010 at 3:19 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 27 Jan 2010, Chris Wilson wrote:
>>
>> Yes, it survives a short torture test that leaks lots of bo objects from
>> X. Obviously this patch depends upon the new interface.
>
> All right. I'll apply my patch, since i'd rather have any half-way complex
> logic for handling mappings in the generic mm code. And then I'll apply
> yours, because now I can look at it without wanting to dig my eyes out.
>
Chris's patch has been reported to cause a regression in hibernate,
I haven't set up a reproducer yet, and it might be a stable issue
(someone bisected it in stable).
https://bugzilla.kernel.org/show_bug.cgi?id=13811
Hopefully I can spend some time tomorrow setting up a machine to test.
Dave.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-06-30 6:54 ` [Intel-gfx] " Dave Airlie
@ 2010-06-30 7:05 ` Chris Wilson
2010-06-30 23:07 ` Linus Torvalds
0 siblings, 1 reply; 52+ messages in thread
From: Chris Wilson @ 2010-06-30 7:05 UTC (permalink / raw)
To: Dave Airlie, Linus Torvalds
Cc: earny, Roman Jarosz, intel-gfx, linux-kernel, jcnengel,
A. Boulan, Hugh Dickins, Pekka Enberg, A Rojas, KOSAKI Motohiro,
rientjes, michael, stable
On Wed, 30 Jun 2010 16:54:07 +1000, Dave Airlie <airlied@gmail.com> wrote:
> Chris's patch has been reported to cause a regression in hibernate,
Reviewing the patch again, we no longer set the default gfpmask on the
inode to contain NORETRY and instead add the NORETRY at the one spot in
the code where we are trying to do a large allocation and our shrinker
would be prevented from running (due to contention on struct_mutex).
I do not know how this causes memory corruption across hibernate and would
appreciate any insights.
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-06-30 7:05 ` Chris Wilson
@ 2010-06-30 23:07 ` Linus Torvalds
2010-07-01 1:24 ` Linus Torvalds
0 siblings, 1 reply; 52+ messages in thread
From: Linus Torvalds @ 2010-06-30 23:07 UTC (permalink / raw)
To: Chris Wilson
Cc: Dave Airlie, earny, Roman Jarosz, intel-gfx, linux-kernel,
jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg, A Rojas,
KOSAKI Motohiro, rientjes, michael, stable
On Wed, Jun 30, 2010 at 12:05 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Reviewing the patch again, we no longer set the default gfpmask on the
> inode to contain NORETRY and instead add the NORETRY at the one spot in
> the code where we are trying to do a large allocation and our shrinker
> would be prevented from running (due to contention on struct_mutex).
>
> I do not know how this causes memory corruption across hibernate and would
> appreciate any insights.
Hmm. More likely is the __GFP_MOVABLE flag, I think.
That commit changes the page cache allocation to use
+ mapping_gfp_mask (mapping) |
+ __GFP_COLD |
+ gfpmask);
if I read it right. And the default mapping_gfp_mask() is
GFP_HIGHUSER_MOVABLE, so I think you get all of
(__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
set by default.
The old code didn't just play games with ~__GFP_NORETRY and change
that at runtime (which was buggy - no locking, no protection, no
nothing), it also initialized the gfp mask. And that code also got
removed:
- /* Basically we want to disable the OOM killer and handle ENOMEM
- * ourselves by sacrificing pages from cached buffers.
- * XXX shmem_file_[gs]et_gfp_mask()
- */
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
- GFP_HIGHUSER |
- __GFP_COLD |
- __GFP_FS |
- __GFP_RECLAIMABLE |
- __GFP_NORETRY |
- __GFP_NOWARN |
- __GFP_NOMEMALLOC);
(and note how it doesn't have __GFP_MOVABLE set).
So I wonder if we shouldn't re-instate that mapping_set_gfp_mask() for
the _initial_ setting when the file descriptor is created. That part
wasn't the bug - the bug was the code that used to try to do that
whole per-allocation dance with the bits incorrectly (ie this part of
the change:
- gfp = i915_gem_object_get_page_gfp_mask(obj);
- i915_gem_object_set_page_gfp_mask(obj, gfp & ~__GFP_NORETRY);
- ret = i915_gem_object_get_pages(obj);
- i915_gem_object_set_page_gfp_mask (obj, gfp);
in that patch).
I could easily see that something would get very unhappy and corrupt
memory if the suspend-to-disk phase ends up compacting memory and
moving the pages around from under the i915 driver.
I dunno. But that seems more likely than the __GFP_NORETRY flag, which
should have no semantic meaning (except making it more likely for
allocations to fail, of course, but that's what the i915 code
_wanted_).
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-06-30 23:07 ` Linus Torvalds
@ 2010-07-01 1:24 ` Linus Torvalds
2010-07-01 1:55 ` KOSAKI Motohiro
` (3 more replies)
0 siblings, 4 replies; 52+ messages in thread
From: Linus Torvalds @ 2010-07-01 1:24 UTC (permalink / raw)
To: Chris Wilson
Cc: Dave Airlie, earny, Roman Jarosz, intel-gfx, linux-kernel,
jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg, A Rojas,
KOSAKI Motohiro, rientjes, michael, stable, Vefa Bicakci
On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That commit changes the page cache allocation to use
>
> + mapping_gfp_mask (mapping) |
> + __GFP_COLD |
> + gfpmask);
>
> if I read it right. And the default mapping_gfp_mask() is
> GFP_HIGHUSER_MOVABLE, so I think you get all of
> (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
> set by default.
.. and then I left out the one flag I _meant_ to have there, namely
__GFP_MOVABLE.
> The old code didn't just play games with ~__GFP_NORETRY and change
> that at runtime (which was buggy - no locking, no protection, no
> nothing), it also initialized the gfp mask. And that code also got
> removed:
In fact, I don't really see why we should use that mapping_gfp_mask()
at all, since all allocations should be going through that
i915_gem_object_get_pages() function anyway. So why not just change
that function to ignore the default gfp mask for the mapping, and just
use the mask that the o915 driver wants?
Btw, why did it want to mark the pages reclaimable?
Anyway, what I'm suggesting somebody who sees this test is just
something like the patch below (whitespace-damage - I'm cutting and
pasting, it's a trivial one-liner). Does this change any behavior?
Vefa?
Linus
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ded3da..ec8ed6b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
mapping = inode->i_mapping;
for (i = 0; i < page_count; i++) {
page = read_cache_page_gfp(mapping, i,
- mapping_gfp_mask (mapping) |
+ GFP_HIGHMEM |
__GFP_COLD |
gfpmask);
if (IS_ERR(page))
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-01 1:24 ` Linus Torvalds
@ 2010-07-01 1:55 ` KOSAKI Motohiro
2010-07-01 10:15 ` Dave Airlie
` (2 subsequent siblings)
3 siblings, 0 replies; 52+ messages in thread
From: KOSAKI Motohiro @ 2010-07-01 1:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: kosaki.motohiro, Chris Wilson, Dave Airlie, earny, Roman Jarosz,
intel-gfx, linux-kernel, jcnengel, A. Boulan, Hugh Dickins,
Pekka Enberg, A Rojas, rientjes, michael, stable, Vefa Bicakci
> On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > That commit changes the page cache allocation to use
> >
> > + mapping_gfp_mask (mapping) |
> > + __GFP_COLD |
> > + gfpmask);
> >
> > if I read it right. And the default mapping_gfp_mask() is
> > GFP_HIGHUSER_MOVABLE, so I think you get all of
> > (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
> > set by default.
>
> .. and then I left out the one flag I _meant_ to have there, namely
> __GFP_MOVABLE.
>
> > The old code didn't just play games with ~__GFP_NORETRY and change
> > that at runtime (which was buggy - no locking, no protection, no
> > nothing), it also initialized the gfp mask. And that code also got
> > removed:
>
> In fact, I don't really see why we should use that mapping_gfp_mask()
> at all, since all allocations should be going through that
> i915_gem_object_get_pages() function anyway. So why not just change
> that function to ignore the default gfp mask for the mapping, and just
> use the mask that the o915 driver wants?
>
> Btw, why did it want to mark the pages reclaimable?
I'm not GEM expert at all. but as far as I read following documentation,
http://lwn.net/Articles/283798/
GEM memory have pin and unpin state and unpined memory can be reclaimed.
but it's just guess. So, I wonder if your patch solve the issue. I don't imazine a memory
state which "swap-out is safe, but compaction is unsafe".
Dave, if you have good documentation which we understand GEM memory management,
could you send us?
- kosaki
>
> Anyway, what I'm suggesting somebody who sees this test is just
> something like the patch below (whitespace-damage - I'm cutting and
> pasting, it's a trivial one-liner). Does this change any behavior?
> Vefa?
>
> Linus
>
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9ded3da..ec8ed6b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
> mapping = inode->i_mapping;
> for (i = 0; i < page_count; i++) {
> page = read_cache_page_gfp(mapping, i,
> - mapping_gfp_mask (mapping) |
> + GFP_HIGHMEM |
> __GFP_COLD |
> gfpmask);
> if (IS_ERR(page))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-01 1:24 ` Linus Torvalds
2010-07-01 1:55 ` KOSAKI Motohiro
@ 2010-07-01 10:15 ` Dave Airlie
2010-07-01 11:19 ` Chris Wilson
2010-07-01 22:34 ` M. Vefa Bicakci
3 siblings, 0 replies; 52+ messages in thread
From: Dave Airlie @ 2010-07-01 10:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Wilson, earny, Roman Jarosz, intel-gfx, linux-kernel,
jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg, A Rojas,
KOSAKI Motohiro, rientjes, michael, stable, Vefa Bicakci
On Thu, Jul 1, 2010 at 11:24 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> That commit changes the page cache allocation to use
>>
>> + mapping_gfp_mask (mapping) |
>> + __GFP_COLD |
>> + gfpmask);
>>
>> if I read it right. And the default mapping_gfp_mask() is
>> GFP_HIGHUSER_MOVABLE, so I think you get all of
>> (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
>> set by default.
>
> .. and then I left out the one flag I _meant_ to have there, namely
> __GFP_MOVABLE.
>
>> The old code didn't just play games with ~__GFP_NORETRY and change
>> that at runtime (which was buggy - no locking, no protection, no
>> nothing), it also initialized the gfp mask. And that code also got
>> removed:
>
> In fact, I don't really see why we should use that mapping_gfp_mask()
> at all, since all allocations should be going through that
> i915_gem_object_get_pages() function anyway. So why not just change
> that function to ignore the default gfp mask for the mapping, and just
> use the mask that the o915 driver wants?
>
> Btw, why did it want to mark the pages reclaimable?
>
> Anyway, what I'm suggesting somebody who sees this test is just
> something like the patch below (whitespace-damage - I'm cutting and
> pasting, it's a trivial one-liner). Does this change any behavior?
> Vefa?
>
I think Linus is on to something, I'll finish my testing tomorrow,
I'm stuck testing this on a laptop with a 4200rpm driver, hibernating
takes quite a long time ;-(
But I have reproduced the initial failure,reverted the patch
reproduced success, and then did a couple of cycles with Linus patch
before I left.
Tomorrow I'll do another 3-4 cycles to confirm.
the patch also needs a couple of __ before GFP_HIGHMEM, in case
anyone else was hacking it.
Dave.
> Linus
>
> ---
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9ded3da..ec8ed6b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2239,7 +2239,7 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
> mapping = inode->i_mapping;
> for (i = 0; i < page_count; i++) {
> page = read_cache_page_gfp(mapping, i,
> - mapping_gfp_mask (mapping) |
> + GFP_HIGHMEM |
> __GFP_COLD |
> gfpmask);
> if (IS_ERR(page))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-01 1:24 ` Linus Torvalds
2010-07-01 1:55 ` KOSAKI Motohiro
2010-07-01 10:15 ` Dave Airlie
@ 2010-07-01 11:19 ` Chris Wilson
2010-07-01 22:34 ` M. Vefa Bicakci
3 siblings, 0 replies; 52+ messages in thread
From: Chris Wilson @ 2010-07-01 11:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, earny, Roman Jarosz, intel-gfx, linux-kernel,
jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg, A Rojas,
KOSAKI Motohiro, rientjes, michael, stable, Vefa Bicakci
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
On Wed, 30 Jun 2010 18:24:04 -0700, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > That commit changes the page cache allocation to use
> >
> > + mapping_gfp_mask (mapping) |
> > + __GFP_COLD |
> > + gfpmask);
> >
> > if I read it right. And the default mapping_gfp_mask() is
> > GFP_HIGHUSER_MOVABLE, so I think you get all of
> > (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
> > set by default.
>
> .. and then I left out the one flag I _meant_ to have there, namely
> __GFP_MOVABLE.
>
> > The old code didn't just play games with ~__GFP_NORETRY and change
> > that at runtime (which was buggy - no locking, no protection, no
> > nothing), it also initialized the gfp mask. And that code also got
> > removed:
That code I added with the original shrinker patch, and the flags lifted
from the shmem defaults, tweaked to what seemed sane with the addition of
NORETRY and friends. I see that i915 is unique in using shmem as the page
allocator, which perhaps explains why this failure is not observed with
the ttm drivers. ttm uses two sets of gfp mask: HIGHUSER and USER | DMA32.
So replacing the mapping_gfp_mask() with HIGHUSER would seem appropriate.
And the interaction of MOVABLE could explain why hibernate broke with the
introduction of GEM.
* turns to his trusty copy of LDD to explain the various meanings of
gfp_t...
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-01 1:24 ` Linus Torvalds
` (2 preceding siblings ...)
2010-07-01 11:19 ` Chris Wilson
@ 2010-07-01 22:34 ` M. Vefa Bicakci
2010-07-01 23:59 ` Linus Torvalds
3 siblings, 1 reply; 52+ messages in thread
From: M. Vefa Bicakci @ 2010-07-01 22:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Wilson, Dave Airlie, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On 01/07/10 04:24 AM, Linus Torvalds wrote:
> On Wed, Jun 30, 2010 at 4:07 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> That commit changes the page cache allocation to use
>>
>> + mapping_gfp_mask (mapping) |
>> + __GFP_COLD |
>> + gfpmask);
>>
>> if I read it right. And the default mapping_gfp_mask() is
>> GFP_HIGHUSER_MOVABLE, so I think you get all of
>> (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | __GFP_HIGHMEM)
>> set by default.
>
> .. and then I left out the one flag I _meant_ to have there, namely
> __GFP_MOVABLE.
>
>> The old code didn't just play games with ~__GFP_NORETRY and change
>> that at runtime (which was buggy - no locking, no protection, no
>> nothing), it also initialized the gfp mask. And that code also got
>> removed:
>
> In fact, I don't really see why we should use that mapping_gfp_mask()
> at all, since all allocations should be going through that
> i915_gem_object_get_pages() function anyway. So why not just change
> that function to ignore the default gfp mask for the mapping, and just
> use the mask that the o915 driver wants?
>
> Btw, why did it want to mark the pages reclaimable?
>
> Anyway, what I'm suggesting somebody who sees this test is just
> something like the patch below (whitespace-damage - I'm cutting and
> pasting, it's a trivial one-liner). Does this change any behavior?
> Vefa?
>
> Linus
Dear Linus,
I made the code change you documented below to a vanilla 2.6.34 tree,
compiled it and tested hibernate/thaw cycles. In total, I tested
16 cycles, with 8 consecutive cycles in one installation (Debian Sid)
and 8 consecutive cycles in another one (Fedora 13). For every cycle,
I tried to run "old" and "new" programs, in terms of whether they were
run in previous cycles. I tried a few extra cycles with uswsusp as well.
Based on my testing, I am happy to report that the change you suggest
fixes the "memory corruption (segfaults) after thaw" issue for me.
I can't thank you enough times for this.
Now, the obligatory question: Could we have this fix applied to 2.6.32,
2.6.33 and 2.6.34 ?
Thanks a lot again!
M. Vefa Bicakci
--- linux-2.6.34/drivers/gpu/drm/i915/i915_gem.c.orig 2010-07-01 17:47:30.000000000 +0000
+++ linux-2.6.34/drivers/gpu/drm/i915/i915_gem.c 2010-07-01 17:54:03.000000000 +0000
@@ -2312,7 +2312,7 @@
mapping = inode->i_mapping;
for (i = 0; i < page_count; i++) {
page = read_cache_page_gfp(mapping, i,
- mapping_gfp_mask (mapping) |
+ __GFP_HIGHMEM |
__GFP_COLD |
gfpmask);
if (IS_ERR(page))
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-01 22:34 ` M. Vefa Bicakci
@ 2010-07-01 23:59 ` Linus Torvalds
2010-07-02 0:06 ` Dave Airlie
0 siblings, 1 reply; 52+ messages in thread
From: Linus Torvalds @ 2010-07-01 23:59 UTC (permalink / raw)
To: M. Vefa Bicakci
Cc: Chris Wilson, Dave Airlie, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci <bicave@superonline.com> wrote:
>
> Based on my testing, I am happy to report that the change you suggest
> fixes the "memory corruption (segfaults) after thaw" issue for me.
> I can't thank you enough times for this.
Hey, goodie. And you're the one to be thanked - bisecting it down to
that commit that wasn't _meant_ to have any real semantic changes
(except for the bug-fix of racy mapping gfp-flags update) is what
really cracked the lid on the problem.
> Now, the obligatory question: Could we have this fix applied to 2.6.32,
> 2.6.33 and 2.6.34 ?
No problem, except we should first determine exactly what flags are
the appropriate ones. My original patch was obviously not even
compile-tested, and I actually meant for people to use GFP_HIGHUSER
rather than __GFP_HIGHMEM. That contains all the "regular" allocation
flags (but not the __GFP_MOVABLE, which is still just a suspicion of
being the core reason for the problem).
And the original DRM code had:
GFP_HIGHUSER |
__GFP_COLD |
__GFP_FS |
__GFP_RECLAIMABLE |
__GFP_NORETRY |
__GFP_NOWARN |
__GFP_NOMEMALLOC
which is not entirely sensible (__GFP_FS is already part of
GFP_HIGHUSER, for example), and two of the flags (NORETRY and NOWARN)
are the ones the driver wants to do conditionally.
But that still leaves the question about __GFP_COLD (probably sane),
__GFP_RECLAIMABLE (I wonder about that one) and __GFP_NOMEMALLOC
(usually used together with NORETRY, and I'm not at all sure it makes
sense as a base flag).
So I suspect the final patch should not look like the one you tested,
but instead likely have
GFP_HIGHUSER | __GFP_COLD
and possibly the __GFP_RECLAIMABLE flag too instead of just the bare
__GFP_HIGHMEM..
(Well, we already had that __GFP_COLD there from before, so it's
really about replacing __GFP_HIGHMEM with something like "GFP_HIGHUSER
| __GFP_RECLAIMABLE").
But its' great to hear that this does seem to be the underlying cause.
If you could test with that GFP_HIGHUSER | __GFP_RECLAIMABLE, that
would be a good thing. After all - maybe the problem was triggered by
some other flag than __GFP_MOVABLE, and as such, having some
additional testing with a bigger set of allocation flags would be a
really good thing.
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-01 23:59 ` Linus Torvalds
@ 2010-07-02 0:06 ` Dave Airlie
2010-07-02 0:49 ` Dave Airlie
0 siblings, 1 reply; 52+ messages in thread
From: Dave Airlie @ 2010-07-02 0:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: M. Vefa Bicakci, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On Fri, Jul 2, 2010 at 9:59 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci <bicave@superonline.com> wrote:
>>
>> Based on my testing, I am happy to report that the change you suggest
>> fixes the "memory corruption (segfaults) after thaw" issue for me.
>> I can't thank you enough times for this.
>
> Hey, goodie. And you're the one to be thanked - bisecting it down to
> that commit that wasn't _meant_ to have any real semantic changes
> (except for the bug-fix of racy mapping gfp-flags update) is what
> really cracked the lid on the problem.
>
>> Now, the obligatory question: Could we have this fix applied to 2.6.32,
>> 2.6.33 and 2.6.34 ?
>
> No problem, except we should first determine exactly what flags are
> the appropriate ones. My original patch was obviously not even
> compile-tested, and I actually meant for people to use GFP_HIGHUSER
> rather than __GFP_HIGHMEM. That contains all the "regular" allocation
> flags (but not the __GFP_MOVABLE, which is still just a suspicion of
> being the core reason for the problem).
>
> And the original DRM code had:
>
> GFP_HIGHUSER |
> __GFP_COLD |
> __GFP_FS |
> __GFP_RECLAIMABLE |
> __GFP_NORETRY |
> __GFP_NOWARN |
> __GFP_NOMEMALLOC
>
> which is not entirely sensible (__GFP_FS is already part of
> GFP_HIGHUSER, for example), and two of the flags (NORETRY and NOWARN)
> are the ones the driver wants to do conditionally.
>
> But that still leaves the question about __GFP_COLD (probably sane),
> __GFP_RECLAIMABLE (I wonder about that one) and __GFP_NOMEMALLOC
> (usually used together with NORETRY, and I'm not at all sure it makes
> sense as a base flag).
>
> So I suspect the final patch should not look like the one you tested,
> but instead likely have
>
> GFP_HIGHUSER | __GFP_COLD
>
> and possibly the __GFP_RECLAIMABLE flag too instead of just the bare
> __GFP_HIGHMEM..
>
> (Well, we already had that __GFP_COLD there from before, so it's
> really about replacing __GFP_HIGHMEM with something like "GFP_HIGHUSER
> | __GFP_RECLAIMABLE").
>
> But its' great to hear that this does seem to be the underlying cause.
> If you could test with that GFP_HIGHUSER | __GFP_RECLAIMABLE, that
> would be a good thing. After all - maybe the problem was triggered by
> some other flag than __GFP_MOVABLE, and as such, having some
> additional testing with a bigger set of allocation flags would be a
> really good thing.
I just sent a patch I tested here with GFP_HIGHUSER | __GFP_COLD
instead, and it resumes okay for me,
I'll play with GFP_RECLAIMABLE now,
If anyone wants to know why nobody uses hibernate, this laptop with a
4200rpm driver boots faster than the hibernate cycle.
Dave.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-02 0:06 ` Dave Airlie
@ 2010-07-02 0:49 ` Dave Airlie
2010-07-02 1:28 ` Linus Torvalds
0 siblings, 1 reply; 52+ messages in thread
From: Dave Airlie @ 2010-07-02 0:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: M. Vefa Bicakci, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On Fri, Jul 2, 2010 at 10:06 AM, Dave Airlie <airlied@gmail.com> wrote:
> On Fri, Jul 2, 2010 at 9:59 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Thu, Jul 1, 2010 at 3:34 PM, M. Vefa Bicakci <bicave@superonline.com> wrote:
>>>
>>> Based on my testing, I am happy to report that the change you suggest
>>> fixes the "memory corruption (segfaults) after thaw" issue for me.
>>> I can't thank you enough times for this.
>>
>> Hey, goodie. And you're the one to be thanked - bisecting it down to
>> that commit that wasn't _meant_ to have any real semantic changes
>> (except for the bug-fix of racy mapping gfp-flags update) is what
>> really cracked the lid on the problem.
>>
>>> Now, the obligatory question: Could we have this fix applied to 2.6.32,
>>> 2.6.33 and 2.6.34 ?
>>
>> No problem, except we should first determine exactly what flags are
>> the appropriate ones. My original patch was obviously not even
>> compile-tested, and I actually meant for people to use GFP_HIGHUSER
>> rather than __GFP_HIGHMEM. That contains all the "regular" allocation
>> flags (but not the __GFP_MOVABLE, which is still just a suspicion of
>> being the core reason for the problem).
>>
>> And the original DRM code had:
>>
>> GFP_HIGHUSER |
>> __GFP_COLD |
>> __GFP_FS |
>> __GFP_RECLAIMABLE |
>> __GFP_NORETRY |
>> __GFP_NOWARN |
>> __GFP_NOMEMALLOC
>>
>> which is not entirely sensible (__GFP_FS is already part of
>> GFP_HIGHUSER, for example), and two of the flags (NORETRY and NOWARN)
>> are the ones the driver wants to do conditionally.
>>
>> But that still leaves the question about __GFP_COLD (probably sane),
>> __GFP_RECLAIMABLE (I wonder about that one) and __GFP_NOMEMALLOC
>> (usually used together with NORETRY, and I'm not at all sure it makes
>> sense as a base flag).
>>
>> So I suspect the final patch should not look like the one you tested,
>> but instead likely have
>>
>> GFP_HIGHUSER | __GFP_COLD
>>
>> and possibly the __GFP_RECLAIMABLE flag too instead of just the bare
>> __GFP_HIGHMEM..
>>
>> (Well, we already had that __GFP_COLD there from before, so it's
>> really about replacing __GFP_HIGHMEM with something like "GFP_HIGHUSER
>> | __GFP_RECLAIMABLE").
>>
>> But its' great to hear that this does seem to be the underlying cause.
>> If you could test with that GFP_HIGHUSER | __GFP_RECLAIMABLE, that
>> would be a good thing. After all - maybe the problem was triggered by
>> some other flag than __GFP_MOVABLE, and as such, having some
>> additional testing with a bigger set of allocation flags would be a
>> really good thing.
>
> I just sent a patch I tested here with GFP_HIGHUSER | __GFP_COLD
> instead, and it resumes okay for me,
>
> I'll play with GFP_RECLAIMABLE now,
>
> If anyone wants to know why nobody uses hibernate, this laptop with a
> 4200rpm driver boots faster than the hibernate cycle.
RECLAIMABLE added also seems fine, of course you can't have
RECLAIMABLE and MOVABLE (I find this out when it oopses on boot).
So I suspect MOVABLE is the problem. but I don't know enough about gfp
flags to know what RECLAIMABLE buys us, and where it might bite us so
I can test some more.
Dave.
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-02 0:49 ` Dave Airlie
@ 2010-07-02 1:28 ` Linus Torvalds
2010-07-17 18:58 ` M. Vefa Bicakci
0 siblings, 1 reply; 52+ messages in thread
From: Linus Torvalds @ 2010-07-02 1:28 UTC (permalink / raw)
To: Dave Airlie
Cc: M. Vefa Bicakci, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On Thu, Jul 1, 2010 at 5:49 PM, Dave Airlie <airlied@gmail.com> wrote:
>
> RECLAIMABLE added also seems fine, of course you can't have
> RECLAIMABLE and MOVABLE (I find this out when it oopses on boot).
Yes. They are both flags for the anti-fragmentation code, and I think
I'll leave the decision as to whether the i915 driver should use
__GFP_RECLAIMABLE to the people who work with and care about the
fragmentation issues. I doubt it matters much in practice, at least
not for the loads that the fragmentation people tend to care most
about.
> So I suspect MOVABLE is the problem. but I don't know enough about gfp
> flags to know what RECLAIMABLE buys us, and where it might bite us so
> I can test some more.
I think I'll just apply your previous tested patch - GFP_HIGHUSER
should take care of all the flags that matter fundamentally, and then
the reclaimable flag is really just a small detail for others to worry
about.
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-02 1:28 ` Linus Torvalds
@ 2010-07-17 18:58 ` M. Vefa Bicakci
2010-07-17 19:15 ` Linus Torvalds
0 siblings, 1 reply; 52+ messages in thread
From: M. Vefa Bicakci @ 2010-07-17 18:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On 02/07/10 04:28 AM, Linus Torvalds wrote:
> On Thu, Jul 1, 2010 at 5:49 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> RECLAIMABLE added also seems fine, of course you can't have
>> RECLAIMABLE and MOVABLE (I find this out when it oopses on boot).
>
> Yes. They are both flags for the anti-fragmentation code, and I think
> I'll leave the decision as to whether the i915 driver should use
> __GFP_RECLAIMABLE to the people who work with and care about the
> fragmentation issues. I doubt it matters much in practice, at least
> not for the loads that the fragmentation people tend to care most
> about.
>
>> So I suspect MOVABLE is the problem. but I don't know enough about gfp
>> flags to know what RECLAIMABLE buys us, and where it might bite us so
>> I can test some more.
>
> I think I'll just apply your previous tested patch - GFP_HIGHUSER
> should take care of all the flags that matter fundamentally, and then
> the reclaimable flag is really just a small detail for others to worry
> about.
>
Dear Linus,
I have bad news regarding your fix for self-reclaim and i915.
Apparently, I haven't tried enough hibernate/thaw cycles while
initially testing your fix.
After applying your fix to 2.6.34.1 and using it for two weeks,
I noticed that every now and then I get a black screen or random
kernel errors after thawing. I thought maybe this might be the
same problem caused by d8e0902806c0bd2ccc4f6a267ff52565a3ec933b .
(It turns out that my guess was right.)
So I compiled two vanilla 2.6.34.1 kernels. One with
d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted to get back
to pre 2.6.32.8 state, and another one with your fix applied.
Then I set up an automated process where the computer would
hibernate, and reboot at the end of the hibernation sequence
(by setting /sys/power/disk to reboot) and then thaw back.
I made this process loop at least 20 times.
The kernel with d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted
was able to hibernate/thaw at least 40 times in one go, while
the one with your fix applied was able to hibernate/thaw at most
17 times (in two separate trials) after which it crashed during
the next thaw.
Is there anything I can do find out the correct flags to use
in addition to GFP_HIGHUSER ? Can I do something like a bisection
for the flags one by one starting from the pre 2.6.32.8 state?
If you could outline a procedure to do this, I would be glad to
follow it.
Sorry to bug you again about this problem because of incomplete
testing on my part.
Regards,
M. Vefa Bicakci
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-17 18:58 ` M. Vefa Bicakci
@ 2010-07-17 19:15 ` Linus Torvalds
2010-07-18 14:27 ` M. Vefa Bicakci
0 siblings, 1 reply; 52+ messages in thread
From: Linus Torvalds @ 2010-07-17 19:15 UTC (permalink / raw)
To: M. Vefa Bicakci
Cc: Dave Airlie, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
On Sat, Jul 17, 2010 at 11:58 AM, M. Vefa Bicakci
<bicave@superonline.com> wrote:
>
> The kernel with d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted
> was able to hibernate/thaw at least 40 times in one go, while
> the one with your fix applied was able to hibernate/thaw at most
> 17 times (in two separate trials) after which it crashed during
> the next thaw.
Ok. I do wonder if the bug is possibly something entirely different,
and the allocation patterns just happen to expose/hide it. Reverting
the original commit should be pretty darn close to applying my fix.
Any remaining issues would seem to be more about the actual bug in the
original code (racing on changing that mapping->gfp_mask witthout any
locking) than about anything else.
> Is there anything I can do find out the correct flags to use
> in addition to GFP_HIGHUSER ? Can I do something like a bisection
> for the flags one by one starting from the pre 2.6.32.8 state?
> If you could outline a procedure to do this, I would be glad to
> follow it.
You can try adding __GFP_RECLAIMABLE | __GFP_NOMEMALLOC to the set of
flags in i915_gem_object_get_pages(). That's what the old code had
(and then it played games with NORETRY|NOWARN). I've attached a patch
(UNTESTED! Maybe it won't compile).
Now, I don't see why those flags would matter, but NOMEMALLOC in
particular does make a difference for memory allocation patterns under
low memory conditions, so maybe it could make a difference.
And if it _does_ make a difference, it would be interesting to know
which of the two flags matter. So try both flags first, and see if
that gets you something reliable. And if it does, remove one of them
and try again - just to see _which_ flag it is that the i915 driver
would care about. That would hopefully give us a hint.
> Sorry to bug you again about this problem because of incomplete
> testing on my part.
Oh, never be sorry for testing even more, and testing something nobody
else bothered to test.
Linus
[-- Attachment #2: diff --]
[-- Type: application/octet-stream, Size: 560 bytes --]
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0743858..98496d4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2241,6 +2241,8 @@ i915_gem_object_get_pages(struct drm_gem_object *obj,
page = read_cache_page_gfp(mapping, i,
GFP_HIGHUSER |
__GFP_COLD |
+ __GFP_RECLAIMABLE |
+ __GFP_NOMEMALLOC |
gfpmask);
if (IS_ERR(page))
goto err_pages;
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-17 19:15 ` Linus Torvalds
@ 2010-07-18 14:27 ` M. Vefa Bicakci
2010-07-18 16:59 ` Linus Torvalds
0 siblings, 1 reply; 52+ messages in thread
From: M. Vefa Bicakci @ 2010-07-18 14:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Airlie, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On 17/07/10 10:15 PM, Linus Torvalds wrote:
> On Sat, Jul 17, 2010 at 11:58 AM, M. Vefa Bicakci
> <bicave@superonline.com> wrote:
>>
>> The kernel with d8e0902806c0bd2ccc4f6a267ff52565a3ec933b reverted
>> was able to hibernate/thaw at least 40 times in one go, while
>> the one with your fix applied was able to hibernate/thaw at most
>> 17 times (in two separate trials) after which it crashed during
>> the next thaw.
>
> Ok. I do wonder if the bug is possibly something entirely different,
> and the allocation patterns just happen to expose/hide it. Reverting
> the original commit should be pretty darn close to applying my fix.
> Any remaining issues would seem to be more about the actual bug in the
> original code (racing on changing that mapping->gfp_mask witthout any
> locking) than about anything else.
>
>> Is there anything I can do find out the correct flags to use
>> in addition to GFP_HIGHUSER ? Can I do something like a bisection
>> for the flags one by one starting from the pre 2.6.32.8 state?
>> If you could outline a procedure to do this, I would be glad to
>> follow it.
>
> You can try adding __GFP_RECLAIMABLE | __GFP_NOMEMALLOC to the set of
> flags in i915_gem_object_get_pages(). That's what the old code had
> (and then it played games with NORETRY|NOWARN). I've attached a patch
> (UNTESTED! Maybe it won't compile).
>
> Now, I don't see why those flags would matter, but NOMEMALLOC in
> particular does make a difference for memory allocation patterns under
> low memory conditions, so maybe it could make a difference.
>
> And if it _does_ make a difference, it would be interesting to know
> which of the two flags matter. So try both flags first, and see if
> that gets you something reliable. And if it does, remove one of them
> and try again - just to see _which_ flag it is that the i915 driver
> would care about. That would hopefully give us a hint.
Dear Linus,
After hours of testing I came up with the following result: We need
to have the __GFP_RECLAIMABLE flag in addition to GFP_HIGHUSER.
First I tested a kernel with both flags added to your fix. I was able
to get more than 60 hibernate/thaw cycles without any errors, so
I thought that was good.
Then I tried a kernel with __GFP_NOMEMALLOC, and I found out that
this kernel wasn't very reliable. In the first trial run, I got a
crash in the second thaw. (Magic Sys-Rq did work.) In the second
trial run, I got a Xorg related kernel Oops in the 12th thaw.
Therefore I concluded that having only __GFP_NOMEMALLOC in addition
to GFP_HIGHUSER was not good enough.
Finally, I tested a kernel with __GFP_RECLAIMABLE. For this one, I did
two trial runs, each with 60 hibernate/thaw cycles. I had no problems
during these runs, so I concluded that __GFP_RECLAIMABLE is the key
flag to use in addition to GFP_HIGHUSER and __GFP_COLD.
I think in a previous e-mail you were suggesting that __GFP_RECLAIMABLE
could be optionally needed for a few technical reasons. To be honest, I
have no idea why it looks like it is needed for proper operation.
As always, it is great to report test results. Hopefully this time I did
enough amount of tests.
Regards,
M. Vefa Bicakci
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Selectively enable self-reclaim
2010-07-18 14:27 ` M. Vefa Bicakci
@ 2010-07-18 16:59 ` Linus Torvalds
0 siblings, 0 replies; 52+ messages in thread
From: Linus Torvalds @ 2010-07-18 16:59 UTC (permalink / raw)
To: M. Vefa Bicakci
Cc: Dave Airlie, Chris Wilson, earny, Roman Jarosz, intel-gfx,
linux-kernel, jcnengel, A. Boulan, Hugh Dickins, Pekka Enberg,
A Rojas, KOSAKI Motohiro, rientjes, michael, stable
On Sun, Jul 18, 2010 at 7:27 AM, M. Vefa Bicakci <bicave@superonline.com> wrote:
>
> After hours of testing I came up with the following result: We need
> to have the __GFP_RECLAIMABLE flag in addition to GFP_HIGHUSER.
Thanks for the extensive testing, and I'm committing the one-liner to
add it, and cc'ing it to stable. I'm pretty certain that there is
something overly fragile in the i915 driver that this flag makes so
much of a difference, but at the same time I'm actually happy that
it's that reclaimable flag, because at least that one was always the
"conceptually makes sense" one.
So I suspected it would be some low-memory issue and the flag that
woudl turn out to matter would be the NOMEMALLOC one, but I'm happy to
have been wrong. Adding __GFP_RECLAIMABLE is sane, although I really
would like to understand why the i915 driver apparently cares so
deeply about the allocation/freeing patterns.
But whatever. Thanks again for being such a thorough tester,
Linus
^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2010-07-18 17:00 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-14 13:15 OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
2010-01-23 0:40 ` David Rientjes
2010-01-25 22:12 ` Roman Jarosz
2010-01-25 1:48 ` KOSAKI Motohiro
2010-01-25 20:47 ` Roman Jarosz
2010-01-26 5:19 ` KOSAKI Motohiro
2010-01-26 7:51 ` A Rojas
2010-01-26 9:06 ` Roman Jarosz
2010-01-26 11:07 ` KOSAKI Motohiro
2010-01-26 12:33 ` Chris Wilson
2010-01-26 13:03 ` KOSAKI Motohiro
2010-01-26 13:18 ` Chris Wilson
2010-01-26 13:59 ` Michael Reinelt
2010-01-26 14:07 ` Michael Reinelt
2010-01-27 0:50 ` KOSAKI Motohiro
2010-01-27 9:56 ` Pekka Enberg
2010-01-27 10:55 ` Linus Torvalds
2010-01-27 11:12 ` Pekka Enberg
2010-01-27 11:14 ` [PATCH] drm/i915: Selectively enable self-reclaim Chris Wilson
2010-01-27 11:20 ` Pekka Enberg
2010-01-27 11:30 ` Michael Reinelt
2010-01-28 3:15 ` Michael Reinelt
2010-01-28 18:21 ` Roman Jarosz
2010-01-27 11:50 ` KOSAKI Motohiro
2010-01-27 12:16 ` Linus Torvalds
2010-01-27 12:28 ` Linus Torvalds
2010-01-27 15:25 ` Chris Wilson
2010-01-27 16:09 ` Linus Torvalds
2010-01-27 17:14 ` Chris Wilson
2010-01-27 17:19 ` Linus Torvalds
2010-01-27 21:03 ` Roman Jarosz
2010-06-30 6:54 ` [Intel-gfx] " Dave Airlie
2010-06-30 7:05 ` Chris Wilson
2010-06-30 23:07 ` Linus Torvalds
2010-07-01 1:24 ` Linus Torvalds
2010-07-01 1:55 ` KOSAKI Motohiro
2010-07-01 10:15 ` Dave Airlie
2010-07-01 11:19 ` Chris Wilson
2010-07-01 22:34 ` M. Vefa Bicakci
2010-07-01 23:59 ` Linus Torvalds
2010-07-02 0:06 ` Dave Airlie
2010-07-02 0:49 ` Dave Airlie
2010-07-02 1:28 ` Linus Torvalds
2010-07-17 18:58 ` M. Vefa Bicakci
2010-07-17 19:15 ` Linus Torvalds
2010-07-18 14:27 ` M. Vefa Bicakci
2010-07-18 16:59 ` Linus Torvalds
2010-01-28 6:37 ` Willy Tarreau
2010-01-26 13:41 ` OOM-Killer kills too much with 2.6.32.2 Roman Jarosz
2010-01-27 0:14 ` KOSAKI Motohiro
2010-01-27 9:53 ` Roman Jarosz
2010-01-26 13:57 ` Pekka Enberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).