* [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
@ 2008-01-04 11:46 Mike Galbraith
2008-01-06 9:42 ` Mike Galbraith
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-04 11:46 UTC (permalink / raw)
To: LKML
[-- Attachment #1: Type: text/plain, Size: 22595 bytes --]
Greetings,
I discovered that I can easily turn my P4/HT 2.6.24.git box into a
doorstop by simply copying a checked-out [~500MB] git repository to a
DVD+RW. This isn't a 2.6.24.git regression, the stock openSuSE 10.3
kernel (2.6.22) does the same. A modest write with no memory pressure
works fine, but add pressure, and box chokes to death every time.
recipe:
dvd+rw-format
mkudffs
mount
/dev/sr0 on /media/LinuxUDF type udf (rw,nosuid,nodev,noatime,uid=0)
cp -av linux-2.6 /media/LinuxUDF/.
Give cp a good head start, and then start a couple parallel kbuilds.
After a while, box slogs to a halt, or perhaps it's just a very VERY
slow crawl. Box is not oom, but it may as well be.
Snippet of serial console output while box is impersonating doorstop:
(264k boot->SysRq-B log available, config.gz attached)
Anybody unfortunate enough to enter shrink_slab() reclaim path (Xorg
did below) ends up sleeping on iprune_mutex, if not forever, for long
enough that I give up and forcibly reboot. I've waited for up to an
hour to see if it would eventually recover, but it never has before I
became impatient. The iprune_mutex appears to be held my kswapd, which
is asleep after having also gone down the shrink_slab() reclaim path.
homer:/root # vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 4 44 8196 70276 609588 0 0 205 229 38 862 70 10 7 13
0 4 44 8196 70276 609588 0 0 0 0 14 37 0 0 32 68
0 4 44 8196 70276 609588 0 0 0 0 7 35 0 0 51 49
0 4 44 8200 70276 609588 0 0 0 0 5 37 0 0 50 50
0 4 44 8200 70276 609588 0 0 0 0 6 41 0 0 35 65
0 4 44 8200 70276 609588 0 0 0 0 6 35 0 0 48 52
0 4 44 8200 70276 609588 0 0 0 0 5 36 0 0 50 50
0 4 44 8200 70276 609588 0 0 0 0 6 33 0 0 52 48
0 4 44 8200 70276 609588 0 0 0 0 5 41 0 0 50 50
0 4 44 8200 70276 609588 0 0 0 0 5 33 0 0 48 52
homer:/root # [ 2188.489078] SysRq : Show Blocked State
[ 2188.492870] task PC stack pid father
[ 2188.498113] pdflush D ef863d7c 0 155 2
[ 2188.503400] ef863d90 00000046 00000002 ef863d7c ef863d74 00000000 00000000 00000960
[ 2188.511783] 00000000 b0406240 b0408f80 ef898e70 ef8990a0 b180bf80 ef863000 00000000
[ 2188.520305] ee2cf5d0 ef86a908 0019c2c6 b01dd062 b014214d 00000000 00000003 00000000
[ 2188.527995] Call Trace:
[ 2188.531469] [<b01dd062>] generic_unplug_device+0x15/0x21
[ 2188.534022] [<b014214d>] getnstimeofday+0x2f/0xd7
[ 2188.539493] [<b02e2689>] io_schedule+0x4f/0x89
[ 2188.539505] [<b01a252d>] sync_buffer+0x30/0x34
[ 2188.539511] [<b02e28a8>] __wait_on_bit+0x42/0x5e
[ 2188.539515] [<b01a24fd>] sync_buffer+0x0/0x34
[ 2188.539525] [<b02e292b>] out_of_line_wait_on_bit+0x67/0x6f
[ 2188.539533] [<b01a24fd>] sync_buffer+0x0/0x34
[ 2188.539543] [<b013ccbd>] wake_bit_function+0x0/0x3c
[ 2188.539558] [<b01a24c4>] __wait_on_buffer+0x24/0x29
[ 2188.539565] [<b01a3ed5>] __bread+0x55/0x8a
[ 2188.539572] [<f0d70e53>] udf_tread+0x3c/0x41 [udf]
[ 2188.539585] [<f0d66add>] udf_update_inode+0x43/0xb8d [udf]
[ 2188.539597] [<b01692fd>] pagevec_lookup_tag+0x24/0x2c
[ 2188.539612] [<b01676bc>] __writepage+0x0/0x25
[ 2188.539661] [<f0d68ca4>] udf_write_inode+0x14/0x20 [udf]
[ 2188.539671] [<b019d9cc>] __writeback_single_inode+0x228/0x306
[ 2188.539689] [<b015fd15>] delayacct_end+0x71/0x79
[ 2188.539699] [<b01e6795>] _atomic_dec_and_lock+0x31/0x5c
[ 2188.539713] [<b019de52>] sync_sb_inodes+0x1c3/0x295
[ 2188.539730] [<b019e100>] writeback_inodes+0x7d/0xac
[ 2188.539739] [<b01685df>] background_writeout+0x98/0xb7
[ 2188.539765] [<b0168abc>] pdflush+0x0/0x1d4
[ 2188.539770] [<b0168bc3>] pdflush+0x107/0x1d4
[ 2188.539777] [<b0168547>] background_writeout+0x0/0xb7
[ 2188.539789] [<b013ca06>] kthread+0x34/0x56
[ 2188.539793] [<b013c9d2>] kthread+0x0/0x56
[ 2188.539800] [<b0104d8b>] kernel_thread_helper+0x7/0x1c
[ 2188.539814] =======================
[ 2188.539818] pdflush D b1811b40 0 156 2
[ 2188.539822] ef864ef4 00000046 00000818 b1811b40 00000002 ef864edc 00000001 db6b063e
[ 2188.539829] 0000019a b0406240 b0408f80 ef8987d0 ef898a00 b1814f80 ef864000 00000202
[ 2188.539836] ef84e000 ee1f7588 b0133013 00000002 00000000 ef864f04 00000202 b013312e
[ 2188.539843] Call Trace:
[ 2188.539870] [<b0133013>] lock_timer_base+0x19/0x35
[ 2188.539881] [<b013312e>] __mod_timer+0x9d/0xac
[ 2188.539894] [<b02e2717>] schedule_timeout+0x44/0xa1
[ 2188.539906] [<b0132cb1>] process_timeout+0x0/0x5
[ 2188.539913] [<b02e2712>] schedule_timeout+0x3f/0xa1
[ 2188.539927] [<b02e255a>] io_schedule_timeout+0x54/0x93
[ 2188.539938] [<b016d3af>] congestion_wait+0x4d/0x61
[ 2188.539946] [<b013cc88>] autoremove_wake_function+0x0/0x35
[ 2188.539958] [<b01686c4>] wb_kupdate+0x9c/0xe2
[ 2188.539980] [<b0168abc>] pdflush+0x0/0x1d4
[ 2188.539984] [<b0168bc3>] pdflush+0x107/0x1d4
[ 2188.539990] [<b0168628>] wb_kupdate+0x0/0xe2
[ 2188.540001] [<b013ca06>] kthread+0x34/0x56
[ 2188.540005] [<b013c9d2>] kthread+0x0/0x56
[ 2188.540012] [<b0104d8b>] kernel_thread_helper+0x7/0x1c
[ 2188.540025] =======================
[ 2188.540027] kswapd0 D 00000004 0 157 2
[ 2188.540031] ef8aacd4 00000046 d8fdb0e8 00000004 00000000 ee2cf5d0 00000000 dec5cace
[ 2188.540037] 00000197 b0406240 b0408f80 ef89b550 ef89b780 b180bf80 ef8aa000 00000000
[ 2188.540044] ee2cf5d0 ee310208 ee2cf5d0 00000000 00000000 ef814914 0039768c 01403000
[ 2188.540051] Call Trace:
[ 2188.540094] [<b02e2689>] io_schedule+0x4f/0x89
[ 2188.540103] [<b01a252d>] sync_buffer+0x30/0x34
[ 2188.540107] [<b02e28a8>] __wait_on_bit+0x42/0x5e
[ 2188.540111] [<b01a24fd>] sync_buffer+0x0/0x34
[ 2188.540120] [<b02e292b>] out_of_line_wait_on_bit+0x67/0x6f
[ 2188.540128] [<b01a24fd>] sync_buffer+0x0/0x34
[ 2188.540138] [<b013ccbd>] wake_bit_function+0x0/0x3c
[ 2188.540150] [<b01a24c4>] __wait_on_buffer+0x24/0x29
[ 2188.540158] [<b01a348a>] sync_dirty_buffer+0x7e/0xc4
[ 2188.540171] [<f0d67400>] udf_update_inode+0x966/0xb8d [udf]
[ 2188.540223] [<f0d6fafc>] extent_trunc+0xac/0x16e [udf]
[ 2188.540244] [<f0d68ca4>] udf_write_inode+0x14/0x20 [udf]
[ 2188.540253] [<b019d9cc>] __writeback_single_inode+0x228/0x306
[ 2188.540284] [<b019db3a>] write_inode_now+0x66/0xb3
[ 2188.540310] [<f0d691f3>] udf_clear_inode+0x33/0x47 [udf]
[ 2188.540318] [<b019549a>] clear_inode+0x62/0x136
[ 2188.540327] [<b0195a79>] dispose_list+0x1a/0xd6
[ 2188.540337] [<b0195caf>] shrink_icache_memory+0x17a/0x233
[ 2188.540352] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.540375] [<b016bcaa>] kswapd+0x314/0x4a6
[ 2188.540411] [<b013cc88>] autoremove_wake_function+0x0/0x35
[ 2188.540422] [<b012099a>] complete+0x3a/0x4a
[ 2188.540433] [<b016b996>] kswapd+0x0/0x4a6
[ 2188.540438] [<b013ca06>] kthread+0x34/0x56
[ 2188.540442] [<b013c9d2>] kthread+0x0/0x56
[ 2188.540449] [<b0104d8b>] kernel_thread_helper+0x7/0x1c
[ 2188.540463] =======================
[ 2188.540485] hald-addon-st D ede4bb5c 0 2308 2202
[ 2188.540489] ede4bb70 00000082 00000002 ede4bb5c ede4bb54 00000000 00000000 ee2cf5d0
[ 2188.540496] ee2cf5d0 b0406240 b0408f80 ee3204b0 ee3206e0 b180bf80 ede4b000 e82600b0
[ 2188.540503] 00000001 ef86a908 0019c2c6 00000002 ef3c3ec8 00000000 00000003 00000000
[ 2188.540509] Call Trace:
[ 2188.540553] [<b02e273c>] schedule_timeout+0x69/0xa1
[ 2188.540560] [<b01d8e70>] elv_drain_elevator+0x15/0x5d
[ 2188.540570] [<b01d9912>] elv_insert+0x107/0x220
[ 2188.540574] [<b01dd0ad>] blk_plug_device+0x3f/0xb1
[ 2188.540590] [<b02e1b97>] wait_for_common+0x6a/0x101
[ 2188.540599] [<b01228e7>] default_wake_function+0x0/0xc
[ 2188.540612] [<b01dcda1>] blk_execute_rq+0x72/0xb3
[ 2188.540618] [<b01dbbb9>] blk_end_sync_rq+0x0/0x23
[ 2188.540635] [<b01a53b2>] bio_add_pc_page+0x23/0x28
[ 2188.540650] [<b01dbd5f>] blk_rq_bio_prep+0x9a/0xae
[ 2188.540658] [<b01dc01b>] blk_rq_append_bio+0x14/0x44
[ 2188.540666] [<b01dc1c4>] blk_rq_map_user+0x11d/0x199
[ 2188.540684] [<b01e03ec>] sg_io+0x196/0x2f3
[ 2188.540737] [<b01e081e>] scsi_cmd_ioctl+0x2d5/0x417
[ 2188.540754] [<f084be00>] scsi_test_unit_ready+0x56/0x95 [scsi_mod]
[ 2188.540819] [<f0aab3a8>] cdrom_ioctl+0x2b/0xdca [cdrom]
[ 2188.540832] [<b018c1c8>] __link_path_walk+0x9eb/0xd0f
[ 2188.540841] [<b017ed94>] cache_free_debugcheck+0xf8/0x240
[ 2188.540852] [<f0aa8074>] media_changed+0x47/0x7e [cdrom]
[ 2188.540868] [<f0ac1068>] sr_block_ioctl+0x47/0x7f [sr_mod]
[ 2188.540886] [<b01de50f>] blkdev_driver_ioctl+0x55/0x5e
[ 2188.540898] [<b01de72f>] blkdev_ioctl+0x217/0x7c8
[ 2188.540913] [<b0181ae1>] get_unused_fd_flags+0xb5/0xce
[ 2188.540925] [<b01e7502>] kobject_get+0xf/0x13
[ 2188.540932] [<b01df0fd>] get_disk+0x1b/0x80
[ 2188.540940] [<b01df169>] exact_lock+0x7/0xd
[ 2188.540944] [<b0252fff>] kobj_lookup+0x157/0x172
[ 2188.540952] [<b01e7502>] kobject_get+0xf/0x13
[ 2188.540964] [<f0ac03a1>] sr_block_open+0x70/0x81 [sr_mod]
[ 2188.540975] [<b01a68e4>] do_open+0xb5/0x28b
[ 2188.540992] [<b01a6c84>] blkdev_open+0x25/0x53
[ 2188.541002] [<b0181c80>] __dentry_open+0x17f/0x1d9
[ 2188.541014] [<b0181d67>] nameidata_to_filp+0x31/0x3a
[ 2188.541020] [<b01a6c5f>] blkdev_open+0x0/0x53
[ 2188.541024] [<b017eadc>] poison_obj+0x1c/0x33
[ 2188.541027] [<b0181da9>] do_filp_open+0x39/0x40
[ 2188.541038] [<b017ed94>] cache_free_debugcheck+0xf8/0x240
[ 2188.541054] [<b01a60c4>] block_ioctl+0x18/0x1d
[ 2188.541060] [<b01a60ac>] block_ioctl+0x0/0x1d
[ 2188.541064] [<b018e68f>] do_ioctl+0x1f/0x6d
[ 2188.541075] [<b018e8e0>] vfs_ioctl+0x203/0x27f
[ 2188.541081] [<b0181e5b>] do_sys_open+0xab/0xc0
[ 2188.541091] [<b018e9b2>] sys_ioctl+0x56/0x68
[ 2188.541101] [<b010413a>] sysenter_past_esp+0x5f/0x85
[ 2188.541118] [<b02e0000>] netlbl_cipsov4_genl_init+0x40/0x57
[ 2188.541135] =======================
[ 2188.541137] Xorg D ede7bd38 0 2340 2318
[ 2188.541141] ede7bd4c 00203082 00000002 ede7bd38 ede7bd30 00000000 00000001 ede7bd94
[ 2188.541147] 00000020 b0406240 b0408f80 ee26e9d0 ee26ec00 b1814f80 ede7b000 b016998a
[ 2188.541154] 00000020 edee0ac8 001a5d24 00000000 00000000 00000000 00000003 00000000
[ 2188.541161] Call Trace:
[ 2188.541184] [<b016998a>] __pagevec_release+0x15/0x1d
[ 2188.541208] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.541222] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.541226] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.541233] [<f083a45c>] mb_cache_shrink_fn+0xde/0xe0 [mbcache]
[ 2188.541250] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.541273] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.541304] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.541331] [<b017c382>] shmem_getpage+0x144/0x68b
[ 2188.541351] [<b0143084>] clocksource_get_next+0x3a/0x40
[ 2188.541355] [<b0141be1>] update_wall_time+0x3f0/0x865
[ 2188.541367] [<b017c9a3>] shmem_fault+0x68/0x97
[ 2188.541382] [<b01cc2fc>] shm_fault+0xc/0xd
[ 2188.541387] [<b016e4ba>] __do_fault+0x55/0x376
[ 2188.541415] [<b01cc2f0>] shm_fault+0x0/0xd
[ 2188.541419] [<b016fb79>] handle_mm_fault+0x11d/0x634
[ 2188.541449] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.541470] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.541478] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.541483] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.541500] [<b02e0000>] netlbl_cipsov4_genl_init+0x40/0x57
[ 2188.541516] =======================
[ 2188.541538] vmstat D e0b1bdec 0 4690 3811
[ 2188.541542] e0b1be00 00200082 00000002 e0b1bdec e0b1bde4 00000000 00000001 ee2291a0
[ 2188.541549] b01bb098 b0406240 b0408f80 ee19c2b0 ee19c4e0 b1814f80 e0b1b000 00000001
[ 2188.541555] 00000004 e0836908 001af82e 00000000 00005c5e 00000000 00000003 00000000
[ 2188.541562] Call Trace:
[ 2188.541576] [<b01bb098>] show_stat+0x791/0x87f
[ 2188.541609] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.541624] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.541628] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.541631] [<b0192fcb>] prune_dcache+0x145/0x189
[ 2188.541647] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.541669] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.541701] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.541728] [<b0167016>] __get_free_pages+0x39/0x47
[ 2188.541734] [<b01b8783>] proc_file_read+0x6d/0x27c
[ 2188.541755] [<b01b8716>] proc_file_read+0x0/0x27c
[ 2188.541761] [<b01b47f6>] proc_reg_read+0x58/0x79
[ 2188.541775] [<b01b479e>] proc_reg_read+0x0/0x79
[ 2188.541781] [<b0183bc6>] vfs_read+0xa1/0x147
[ 2188.541788] [<b0182ea1>] vfs_llseek+0x36/0x3c
[ 2188.541798] [<b018403c>] sys_read+0x41/0x6a
[ 2188.541810] [<b010413a>] sysenter_past_esp+0x5f/0x85
[ 2188.541839] =======================
[ 2188.541841] cp D 00000004 0 4911 3894
[ 2188.541844] e0b38b14 00200082 0000024e 00000004 00000000 ee2cf5d0 00000000 96ccdff3
[ 2188.541851] 00000199 b0406240 b0408f80 e0845710 e0845940 b180bf80 e0b38000 00000000
[ 2188.541858] ee2cf5d0 e09c5208 ee2cf5d0 00000002 00000000 edeb8914 0039f4ce 01403000
[ 2188.541865] Call Trace:
[ 2188.541909] [<b02e2689>] io_schedule+0x4f/0x89
[ 2188.541918] [<b01a252d>] sync_buffer+0x30/0x34
[ 2188.541921] [<b02e28a8>] __wait_on_bit+0x42/0x5e
[ 2188.541925] [<b01a24fd>] sync_buffer+0x0/0x34
[ 2188.541935] [<b02e292b>] out_of_line_wait_on_bit+0x67/0x6f
[ 2188.541943] [<b01a24fd>] sync_buffer+0x0/0x34
[ 2188.541953] [<b013ccbd>] wake_bit_function+0x0/0x3c
[ 2188.541966] [<b01a24c4>] __wait_on_buffer+0x24/0x29
[ 2188.541974] [<b01a3ed5>] __bread+0x55/0x8a
[ 2188.541981] [<f0d70e53>] udf_tread+0x3c/0x41 [udf]
[ 2188.541991] [<f0d66add>] udf_update_inode+0x43/0xb8d [udf]
[ 2188.542003] [<b01692fd>] pagevec_lookup_tag+0x24/0x2c
[ 2188.542017] [<b01676bc>] __writepage+0x0/0x25
[ 2188.542050] [<b017e56a>] dbg_redzone1+0xe/0x19
[ 2188.542056] [<b017eb68>] cache_alloc_debugcheck_after+0x75/0x1a9
[ 2188.542073] [<f0d68ca4>] udf_write_inode+0x14/0x20 [udf]
[ 2188.542083] [<b019d9cc>] __writeback_single_inode+0x228/0x306
[ 2188.542106] [<b01e6795>] _atomic_dec_and_lock+0x31/0x5c
[ 2188.542118] [<b019de52>] sync_sb_inodes+0x1c3/0x295
[ 2188.542135] [<b019e100>] writeback_inodes+0x7d/0xac
[ 2188.542143] [<b01682fd>] balance_dirty_pages_ratelimited_nr+0x21f/0x33c
[ 2188.542188] [<b0162c9f>] generic_file_buffered_write+0x1c7/0x65f
[ 2188.542217] [<b013ff2d>] ktime_get_ts+0x16/0x44
[ 2188.542226] [<b015fd15>] delayacct_end+0x71/0x79
[ 2188.542250] [<b01633e4>] __generic_file_aio_write_nolock+0x2ad/0x50d
[ 2188.542266] [<b0161859>] file_read_actor+0xcf/0xd9
[ 2188.542289] [<b016178a>] file_read_actor+0x0/0xd9
[ 2188.542303] [<b01636a9>] generic_file_aio_write+0x65/0xd3
[ 2188.542311] [<b012e8e7>] current_fs_time+0x13/0x15
[ 2188.542328] [<f0d6442c>] udf_file_aio_write+0x4e/0xfc [udf]
[ 2188.542348] [<b018323f>] do_sync_write+0xd2/0x10e
[ 2188.542377] [<b013cc88>] autoremove_wake_function+0x0/0x35
[ 2188.542396] [<b0145517>] tick_program_event+0x38/0x58
[ 2188.542417] [<b018316d>] do_sync_write+0x0/0x10e
[ 2188.542423] [<b0183a7f>] vfs_write+0xa4/0x14a
[ 2188.542436] [<b01840a6>] sys_write+0x41/0x6a
[ 2188.542448] [<b010413a>] sysenter_past_esp+0x5f/0x85
[ 2188.542478] =======================
[ 2188.542483] cc1 D b1808b40 0 14511 14510
[ 2188.542486] d6f87e04 00200082 00000400 b1808b40 00000002 d6f87dec 00000000 93edb8a2
[ 2188.542493] 00000198 b0406240 b0408f80 d70ac3f0 d70ac620 b180bf80 d6f87000 00000000
[ 2188.542500] 00000020 ee3103c8 001902d9 b8accb99 ffffffff 00000001 00000003 00000000
[ 2188.542506] Call Trace:
[ 2188.542551] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.542566] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.542570] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.542586] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.542609] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.542640] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.542667] [<b016fc89>] handle_mm_fault+0x22d/0x634
[ 2188.542678] [<b0104c08>] apic_timer_interrupt+0x28/0x30
[ 2188.542701] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.542723] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.542730] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.542736] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.542752] [<b02e0000>] netlbl_cipsov4_genl_init+0x40/0x57
[ 2188.542768] =======================
[ 2188.542771] cc1 D b03ac500 0 14878 14876
[ 2188.542775] cc474e04 00200086 b11d35a0 b03ac500 b016a58c 00000001 00000001 2eedb85d
[ 2188.542782] 00000198 b0406240 b0408f80 e0845070 e08452a0 b1814f80 cc474000 00000000
[ 2188.542789] 00000020 e35ca048 cc474e54 00000000 00000000 b0406560 b0406560 b03ac880
[ 2188.542795] Call Trace:
[ 2188.542803] [<b016a58c>] isolate_lru_pages+0x5f/0x1bb
[ 2188.542842] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.542857] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.542861] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.542865] [<b0192fcb>] prune_dcache+0x145/0x189
[ 2188.542879] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.542903] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.542934] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.542961] [<b016fc89>] handle_mm_fault+0x22d/0x634
[ 2188.542991] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.543013] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.543020] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.543026] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.543042] [<b02e0000>] netlbl_cipsov4_genl_init+0x40/0x57
[ 2188.543058] =======================
[ 2188.543061] cc1 D b03ac080 0 14953 14952
[ 2188.543064] e3480e04 00200086 b100a340 b03ac080 b016a58c 00000001 00000001 2f20bdcf
[ 2188.543071] 00000198 b0406240 b0408f80 e0880950 e0880b80 b1814f80 e3480000 00000000
[ 2188.543078] b03ac080 c65f6588 e3480e54 00000000 00000000 b0406560 b0406560 b03ac400
[ 2188.543085] Call Trace:
[ 2188.543093] [<b016a58c>] isolate_lru_pages+0x5f/0x1bb
[ 2188.543133] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.543147] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.543151] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.543155] [<b0192f7b>] prune_dcache+0xf5/0x189
[ 2188.543170] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.543192] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.543223] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.543250] [<b016fc89>] handle_mm_fault+0x22d/0x634
[ 2188.543281] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.543302] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.543310] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.543315] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.543344] =======================
[ 2188.543346] cc1 D d717de4c 0 15009 15008
[ 2188.543350] d717de04 00200082 b12d9720 d717de4c 00000001 00000001 00000000 ebc981b4
[ 2188.543357] 00000197 b0406240 b0408f80 cc6de2f0 cc6de520 b180bf80 d717d000 00000000
[ 2188.543364] 00000001 ee310208 d717de44 00000000 00000000 b03ac400 00000017 d717dea8
[ 2188.543370] Call Trace:
[ 2188.543414] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.543429] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.543433] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.543436] [<b0192fcb>] prune_dcache+0x145/0x189
[ 2188.543451] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.543473] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.543504] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.543530] [<b016fc89>] handle_mm_fault+0x22d/0x634
[ 2188.543561] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.543581] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.543589] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.543594] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.543611] [<b02e0000>] netlbl_cipsov4_genl_init+0x40/0x57
[ 2188.543627] =======================
[ 2188.543630] cc1 D e371adf0 0 15093 15092
[ 2188.543633] e371ae04 00200086 00000002 e371adf0 e371ade8 00000000 00000001 e371ae4c
[ 2188.543640] 00000020 b0406240 b0408f80 eded50b0 eded52e0 b1814f80 e371a000 b016998a
[ 2188.543647] 00000020 c65f6748 0019034d 00000000 00000000 00000000 00000003 00000000
[ 2188.543653] Call Trace:
[ 2188.543677] [<b016998a>] __pagevec_release+0x15/0x1d
[ 2188.543701] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.543716] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.543720] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.543724] [<b0192f7b>] prune_dcache+0xf5/0x189
[ 2188.543738] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.543761] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.543792] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.543819] [<b016fc89>] handle_mm_fault+0x22d/0x634
[ 2188.543849] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.543870] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.543877] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.543883] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.543899] [<b02e0000>] netlbl_cipsov4_genl_init+0x40/0x57
[ 2188.543915] =======================
[ 2188.543918] cc1 D d6d33df0 0 15147 15146
[ 2188.543921] d6d33e04 00200086 00000002 d6d33df0 d6d33de8 00000000 00000000 b013ff2d
[ 2188.543928] 03312780 b0406240 b0408f80 cc7dcfb0 cc7dd1e0 b180bf80 d6d33000 db730a00
[ 2188.543935] 000001c3 d7015588 001908bd 000001c3 b18093a0 00000000 00000003 00000000
[ 2188.543941] Call Trace:
[ 2188.543953] [<b013ff2d>] ktime_get_ts+0x16/0x44
[ 2188.543987] [<b02e2abe>] __mutex_lock_slowpath+0x57/0x90
[ 2188.544002] [<b02e293d>] mutex_lock+0xa/0xb
[ 2188.544006] [<b0195b8d>] shrink_icache_memory+0x58/0x233
[ 2188.544010] [<b0192f7b>] prune_dcache+0xf5/0x189
[ 2188.544024] [<b016b8c3>] shrink_slab+0x12e/0x197
[ 2188.544046] [<b016c2b7>] try_to_free_pages+0x182/0x267
[ 2188.544077] [<b0166dd9>] __alloc_pages+0x146/0x34a
[ 2188.544104] [<b016fc89>] handle_mm_fault+0x22d/0x634
[ 2188.544134] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 2188.544155] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 2188.544162] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 2188.544168] [<b02e3d9a>] error_code+0x72/0x78
[ 2188.544197] =======================
[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 13658 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-04 11:46 [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop Mike Galbraith
@ 2008-01-06 9:42 ` Mike Galbraith
2008-01-06 18:01 ` Mike Galbraith
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-06 9:42 UTC (permalink / raw)
To: LKML
FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
[ 959.419364] SysRq : Show Blocked State
[ 959.419364] task PC stack pid father
[ 959.419364] kswapd0 D 00000000 0 158 2
[ 959.419364] ef90bec0 00000046 00000000 00000000 00000000 00000020 00000001 00000000
[ 959.419364] 8d4fb4b9 000000b3 b040d300 b040d300 ef8ab5f0 ef8ab83c b1815300 ef90b000
[ 959.419364] b016b41a 00000020 df606740 ef90bf10 00168208 00000000 b040a8e0 b040a8e0
[ 959.419364] Call Trace:
[ 959.419364] [<b016b41a>] __pagevec_release+0x15/0x1d
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<f086c45c>] mb_cache_shrink_fn+0xde/0xe0 [mbcache]
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016d6e2>] kswapd+0x314/0x49f
[ 959.419364] [<b013e1a8>] autoremove_wake_function+0x0/0x35
[ 959.419364] [<b016d3ce>] kswapd+0x0/0x49f
[ 959.419364] [<b013df26>] kthread+0x34/0x56
[ 959.419364] [<b013def2>] kthread+0x0/0x56
[ 959.419364] [<b0104d7b>] kernel_thread_helper+0x7/0x1c
[ 959.419364] =======================
[ 959.419364] Xorg D eeeacd38 0 2366 2343
[ 959.419364] eeeacd4c 00203082 00000002 eeeacd38 eeeacd30 00000000 00000001 00000000
[ 959.419364] 00000000 ffffffff b040d300 b040d300 ee1fa8f0 ee1fab3c b1815300 eeeac000
[ 959.419364] b016b41a 00000020 df997740 00289a1f 00000000 00000000 00000000 00000003
[ 959.419364] Call Trace:
[ 959.419364] [<b016b41a>] __pagevec_release+0x15/0x1d
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b017dc5c>] shmem_getpage+0x144/0x691
[ 959.419364] [<b017e283>] shmem_fault+0x68/0x97
[ 959.419364] [<b01cbe4c>] shm_fault+0xc/0xd
[ 959.419364] [<b016feda>] __do_fault+0x55/0x376
[ 959.419364] [<b0126f30>] scheduler_tick+0x12f/0x3de
[ 959.419364] [<b01cbe40>] shm_fault+0x0/0xd
[ 959.419364] [<b0171583>] handle_mm_fault+0x11d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] =======================
[ 959.419364] top D b0104bf8 0 4190 3771
[ 959.419364] eef49e38 00200086 b03af280 b0104bf8 ffffffe0 ffffffed 00000000 b03af280
[ 959.419364] c23aaad8 000000d5 b040d300 b040d300 e83aeaf0 e83aed3c b180c300 eef49000
[ 959.419364] 00000000 00000020 ee23fac0 eef49e88 002da5f3 00000000 b040a8e0 b040a8e0
[ 959.419364] Call Trace:
[ 959.419364] [<b0104bf8>] apic_timer_interrupt+0x28/0x30
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0182217>] nameidata_to_filp+0x31/0x3a
[ 959.419364] [<b0168ae3>] __get_free_pages+0x39/0x47
[ 959.419364] [<b01b6ea8>] proc_info_read+0x39/0xa9
[ 959.419364] [<b01b6e6f>] proc_info_read+0x0/0xa9
[ 959.419364] [<b0184076>] vfs_read+0xa1/0x147
[ 959.419364] [<b01844ec>] sys_read+0x41/0x6a
[ 959.419364] [<b010412a>] sysenter_past_esp+0x5f/0x85
[ 959.419364] =======================
[ 959.419364] cp D c0826cd4 0 4434 3846
[ 959.419364] c0826ce8 00200082 00000002 c0826cd4 c0826ccc 00000000 00000000 00000000
[ 959.419364] 00000000 ffffffff b040d300 b040d300 e83ae430 e83ae67c b180c300 c0826000
[ 959.419364] b1512dc0 b03af280 df606740 00286237 00000000 00000000 00000000 00000003
[ 959.419364] Call Trace:
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b019330b>] prune_dcache+0xf5/0x189
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b016a891>] __do_page_cache_readahead+0x115/0x22e
[ 959.419364] [<b0163b56>] do_generic_mapping_read+0x160/0x45b
[ 959.419364] [<b016326a>] file_read_actor+0x0/0xd9
[ 959.419364] [<b0165636>] generic_file_aio_read+0x101/0x198
[ 959.419364] [<b016326a>] file_read_actor+0x0/0xd9
[ 959.419364] [<b01837fd>] do_sync_read+0xd2/0x10e
[ 959.419364] [<b013e1a8>] autoremove_wake_function+0x0/0x35
[ 959.419364] [<b0146a97>] tick_program_event+0x38/0x58
[ 959.419364] [<b018372b>] do_sync_read+0x0/0x10e
[ 959.419364] [<b0184076>] vfs_read+0xa1/0x147
[ 959.419364] [<b01844ec>] sys_read+0x41/0x6a
[ 959.419364] [<b010412a>] sysenter_past_esp+0x5f/0x85
[ 959.419364] =======================
[ 959.419364] as D b154cb40 0 20046 20044
[ 959.419364] ef198e04 00200086 01312d00 b154cb40 b03af280 b016bfdc 00000001 b03af280
[ 959.419364] a0dde696 000000b2 b040d300 b040d300 df53c070 df53c2bc b1815300 ef198000
[ 959.419364] 00000000 00000020 c90c0200 ef198e54 00000000 00000000 b040a8e0 b040a8e0
[ 959.419364] Call Trace:
[ 959.419364] [<b016bfdc>] isolate_lru_pages+0x5f/0x1bb
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b019330b>] prune_dcache+0xf5/0x189
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0171693>] handle_mm_fault+0x22d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] [<b02e0000>] netlbl_secattr_catmap_setbit+0x6d/0x8b
[ 959.419364] =======================
[ 959.419364] pdflush D 00008784 0 20121 2
[ 959.419364] ea130d9c 00000046 beaa8a90 00008784 00000004 00000000 00000000 0fd00000
[ 959.419364] 618d6a4e 000000df b040d300 b040d300 d6d2b5f0 d6d2b83c b180c300 ea130000
[ 959.419364] 00000000 00000008 ef182200 beaa8a90 00000001 00000000 df610de0 002a5bec
[ 959.419364] Call Trace:
[ 959.419364] [<b02e3b7f>] io_schedule+0x4f/0x89
[ 959.419364] [<b01a287d>] sync_buffer+0x30/0x34
[ 959.419364] [<b02e3d8f>] __wait_on_bit+0x42/0x5e
[ 959.419364] [<b01a284d>] sync_buffer+0x0/0x34
[ 959.419364] [<b02e3e12>] out_of_line_wait_on_bit+0x67/0x6f
[ 959.419364] [<b01a284d>] sync_buffer+0x0/0x34
[ 959.419364] [<b013e1dd>] wake_bit_function+0x0/0x3c
[ 959.419364] [<b01a2814>] __wait_on_buffer+0x24/0x29
[ 959.419364] [<b01a4225>] __bread+0x55/0x8a
[ 959.419364] [<f0e9ce53>] udf_tread+0x3c/0x41 [udf]
[ 959.419364] [<f0e92add>] udf_update_inode+0x43/0xb8d [udf]
[ 959.419364] [<b016ad8d>] pagevec_lookup_tag+0x24/0x2c
[ 959.419364] [<b016917c>] __writepage+0x0/0x25
[ 959.419364] [<f0e94ca4>] udf_write_inode+0x14/0x20 [udf]
[ 959.419364] [<b019dd1c>] __writeback_single_inode+0x228/0x306
[ 959.419364] [<b0161845>] delayacct_end+0x71/0x79
[ 959.419364] [<b01e6005>] _atomic_dec_and_lock+0x31/0x5c
[ 959.419364] [<b019e1a2>] sync_sb_inodes+0x1c3/0x294
[ 959.419364] [<b019e450>] writeback_inodes+0x7d/0xac
[ 959.419364] [<b016a14d>] wb_kupdate+0x7e/0xe2
[ 959.419364] [<b016a56c>] pdflush+0x0/0x1d4
[ 959.419364] [<b016a673>] pdflush+0x107/0x1d4
[ 959.419364] [<b016a0cf>] wb_kupdate+0x0/0xe2
[ 959.419364] [<b013df26>] kthread+0x34/0x56
[ 959.419364] [<b013def2>] kthread+0x0/0x56
[ 959.419364] [<b0104d7b>] kernel_thread_helper+0x7/0x1c
[ 959.419364] =======================
[ 959.419364] cc1 D b1808f00 0 20150 20149
[ 959.419364] efbf2e04 00200082 00000555 b1808f00 00000002 efbf2dec 00000000 0000000c
[ 959.419364] 16e6490f 000000d5 b040d300 b040d300 c97ab130 c97ab37c b180c300 efbf2000
[ 959.419364] 00000000 00000020 e6dccc80 0024beb7 00000000 00000000 00000001 00000003
[ 959.419364] Call Trace:
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0171693>] handle_mm_fault+0x22d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] =======================
[ 959.419364] cc1 D def92b70 0 20181 20180
[ 959.419364] ef1fdc18 00200082 ef4f9dfc def92b70 00000004 00000000 00000001 0fd00000
[ 959.419364] 8ae5a1e1 000000b2 b040d300 b040d300 cc65eb70 cc65edbc b1815300 ef1fd000
[ 959.419364] 00000000 b1812a60 edfe4e40 b016b3a8 00000000 00000000 ee1e34f0 00277786
[ 959.419364] Call Trace:
[ 959.419364] [<b016b3a8>] mark_page_accessed+0x29/0x30
[ 959.419364] [<b02e3b7f>] io_schedule+0x4f/0x89
[ 959.419364] [<b01a287d>] sync_buffer+0x30/0x34
[ 959.419364] [<b02e3d8f>] __wait_on_bit+0x42/0x5e
[ 959.419364] [<b01a284d>] sync_buffer+0x0/0x34
[ 959.419364] [<b02e3e12>] out_of_line_wait_on_bit+0x67/0x6f
[ 959.419364] [<b01a284d>] sync_buffer+0x0/0x34
[ 959.419364] [<b013e1dd>] wake_bit_function+0x0/0x3c
[ 959.419364] [<b01a2814>] __wait_on_buffer+0x24/0x29
[ 959.419364] [<b01a37da>] sync_dirty_buffer+0x7e/0xc4
[ 959.419364] [<f0e93400>] udf_update_inode+0x966/0xb8d [udf]
[ 959.419364] [<f0e9bafc>] extent_trunc+0xac/0x16e [udf]
[ 959.419364] [<f0e94ca4>] udf_write_inode+0x14/0x20 [udf]
[ 959.419364] [<b019dd1c>] __writeback_single_inode+0x228/0x306
[ 959.419364] [<b019de8a>] write_inode_now+0x66/0xb3
[ 959.419364] [<f0e951f3>] udf_clear_inode+0x33/0x47 [udf]
[ 959.419364] [<b01957ea>] clear_inode+0x62/0x136
[ 959.419364] [<b0195dd4>] dispose_list+0x1a/0xd6
[ 959.419364] [<b019600a>] shrink_icache_memory+0x17a/0x233
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0171693>] handle_mm_fault+0x22d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] [<b02e0000>] netlbl_secattr_catmap_setbit+0x6d/0x8b
[ 959.419364] =======================
[ 959.419364] cc1 D df737df0 0 20224 20222
[ 959.419364] df737e04 00200082 00000002 df737df0 df737de8 00000000 00000001 00000002
[ 959.419364] df737e4c 00000020 b040d300 b040d300 df63ef30 df63f17c b1815300 df737000
[ 959.419364] b016b41a 00000020 ee18f580 0024cb24 00000000 00000000 00000000 00000003
[ 959.419364] Call Trace:
[ 959.419364] [<b016b41a>] __pagevec_release+0x15/0x1d
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b019330b>] prune_dcache+0xf5/0x189
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0171693>] handle_mm_fault+0x22d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] [<b02e0000>] netlbl_secattr_catmap_setbit+0x6d/0x8b
[ 959.419364] =======================
[ 959.419364] cc1 D cb5ccdf0 0 20242 20241
[ 959.419364] cb5cce04 00200086 00000002 cb5ccdf0 cb5ccde8 00000000 00000000 b1808120
[ 959.419364] 00000000 00000000 b040d300 b040d300 e6fb9870 e6fb9abc b180c300 cb5cc000
[ 959.419364] b0104bf8 b1afd240 c90c0900 0024c96b b03b09a4 0000003f ffffffff 00000003
[ 959.419364] Call Trace:
[ 959.419364] [<b0104bf8>] apic_timer_interrupt+0x28/0x30
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b019335b>] prune_dcache+0x145/0x189
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0171693>] handle_mm_fault+0x22d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] [<b02e0000>] netlbl_secattr_catmap_setbit+0x6d/0x8b
[ 959.419364] =======================
[ 959.419364] cc1 D b15407e0 0 20252 20251
[ 959.419364] da5d0e04 00200082 da5d0df8 b15407e0 b03af280 b016bfdc 00000001 b03af280
[ 959.419364] 2d90fbe6 000000b3 b040d300 b040d300 df63e870 df63eabc b1815300 da5d0000
[ 959.419364] 00000000 00000020 d0aa6e40 da5d0e54 00000000 00000000 b040a8e0 b040a8e0
[ 959.419364] Call Trace:
[ 959.419364] [<b016bfdc>] isolate_lru_pages+0x5f/0x1bb
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0171693>] handle_mm_fault+0x22d/0x62f
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0117f47>] smp_apic_timer_interrupt+0x59/0x84
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] [<b02e0000>] netlbl_secattr_catmap_setbit+0x6d/0x8b
[ 959.419364] =======================
[ 959.419364] bash D b4354dc0 0 20276 3582
[ 959.419364] b4354dd4 00000082 00000002 b4354dc0 b4354db8 00000000 00000001 0000000c
[ 959.419364] b4354e1c 00000020 b040d300 b040d300 c9ba2270 c9ba24bc b1815300 b4354000
[ 959.419364] b016b41a 00000020 c3584c80 0027f8af 00000000 00000000 ffffffff 00000003
[ 959.419364] Call Trace:
[ 959.419364] [<b016b41a>] __pagevec_release+0x15/0x1d
[ 959.419364] [<b02e3fa5>] __mutex_lock_slowpath+0x57/0x90
[ 959.419364] [<b02e3e24>] mutex_lock+0xa/0xb
[ 959.419364] [<b0195ee8>] shrink_icache_memory+0x58/0x233
[ 959.419364] [<b016d2fe>] shrink_slab+0x129/0x18f
[ 959.419364] [<b016dce7>] try_to_free_pages+0x182/0x267
[ 959.419364] [<b01688a3>] __alloc_pages+0x140/0x347
[ 959.419364] [<b0170418>] do_wp_page+0x87/0x3f1
[ 959.419364] [<b01718b5>] handle_mm_fault+0x44f/0x62f
[ 959.419364] [<b012934c>] wake_up_new_task+0x77/0x93
[ 959.419364] [<b011ca6c>] do_page_fault+0xd0/0x5d4
[ 959.419364] [<b0136005>] recalc_sigpending+0xb/0x30
[ 959.419364] [<b0136092>] sigprocmask+0x68/0xc3
[ 959.419364] [<b0102241>] sys_clone+0x36/0x3b
[ 959.419364] [<b011c99c>] do_page_fault+0x0/0x5d4
[ 959.419364] [<b02e527a>] error_code+0x72/0x78
[ 959.419364] [<b02e0000>] netlbl_secattr_catmap_setbit+0x6d/0x8b
[ 959.419364] =======================
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-06 9:42 ` Mike Galbraith
@ 2008-01-06 18:01 ` Mike Galbraith
2008-01-06 20:29 ` Andrew Morton
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-06 18:01 UTC (permalink / raw)
To: LKML
On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
Ugh, horrid device IO ==> horrid VM AFIKT. I'll continue rummaging, but
I wonder, am I doing something _so_ stupid as to warrant zero response?
-Mike
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-06 18:01 ` Mike Galbraith
@ 2008-01-06 20:29 ` Andrew Morton
2008-01-07 5:33 ` Mike Galbraith
2008-01-08 11:05 ` Mike Galbraith
0 siblings, 2 replies; 16+ messages in thread
From: Andrew Morton @ 2008-01-06 20:29 UTC (permalink / raw)
To: Mike Galbraith; +Cc: LKML
On Sun, 06 Jan 2008 19:01:10 +0100 Mike Galbraith <efault@gmx.de> wrote:
>
> On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> > FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
>
> Ugh, horrid device IO ==> horrid VM AFIKT. I'll continue rummaging, but
> I wonder, am I doing something _so_ stupid as to warrant zero response?
>
Copying linux-mm might have helped. Bad time of year, too.
>From the traces it looks like all IO has stopped and everyone is waiting
(directly or indirectly) for certain IO completions. Is that really true,
or is IO still dribbling along?
>From the kswapd0 trace it would appear that UDF is doing synchronous writes
(udf_update_inode->sync_dirty_buffer) which perhaps is making things
mightily slow.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-06 20:29 ` Andrew Morton
@ 2008-01-07 5:33 ` Mike Galbraith
2008-01-07 5:55 ` Mike Galbraith
2008-01-08 11:05 ` Mike Galbraith
1 sibling, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-07 5:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML
On Sun, 2008-01-06 at 12:29 -0800, Andrew Morton wrote:
> On Sun, 06 Jan 2008 19:01:10 +0100 Mike Galbraith <efault@gmx.de> wrote:
>
> >
> > On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> > > FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
> >
> > Ugh, horrid device IO ==> horrid VM AFIKT. I'll continue rummaging, but
> > I wonder, am I doing something _so_ stupid as to warrant zero response?
> >
>
> Copying linux-mm might have helped. Bad time of year, too.
Thanks for the reply, I was getting alll paranoid that I was being
really dense, ergo the ping.
> >From the traces it looks like all IO has stopped and everyone is waiting
> (directly or indirectly) for certain IO completions. Is that really true,
> or is IO still dribbling along?
It's dribbling along. I drastically improved the situation by bouncing
people off the exclusion wall instead of synchronizing, but the poor sod
who acquires prune_mutex is in purgatory for a very long time.
(undoes butchery)
> >From the kswapd0 trace it would appear that UDF is doing synchronous writes
> (udf_update_inode->sync_dirty_buffer) which perhaps is making things
> mightily slow.
Even synchronous writes shouldn't cause minutes long hangs surely :)
This /dev/sr0 IO seems to be getting jammed up something terrible. I
formatted the dvd ext2 and tried the same copy. It didn't jam up the
whole box (well, yet, it's still zooming along at mach 0.0000000001)
doing parallel kbuilds, but when I started a bonnie, the poor thing
instantly got nailed to the floor. I kill -9'd it about a half an hour
ago, and it has yet to respond. Every now and again there's a burst of
activity from cp, but bonnie is stuck for the duration it seems. I'll
find out.
<twiddle twiddle twiddle>
The 515MB cp finished after an hour and change. When bonnie exits I'll
be able to see what the throughput was.
<twiddle++>
bonnie finally exited. uptime is now 1:22. cp started right after
boot... throughput very bad.
I would almost swear I copied to that dvd drive when it was /dev/hdc
(before I upgraded to openSuSE 10.3 and got all modern) and it worked
well enough to not attract my attention. I guess I need to figure out
how to reacquire /dev/hdc and try again.
[ 1687.358723] SysRq : Show Blocked State
[ 1687.358729] task PC stack pid father
[ 1687.358729] pdflush D 00000140 0 156 2
[ 1687.358729] ee172de4 00000046 e0791550 00000140 00000008 00000000 00000000 00b00000
[ 1687.358729] b0d3bb78 00000188 b040d300 b040d300 ef8ab5f0 ef8ab83c b180c300 ee172000
[ 1687.358729] 00000000 ee2c5550 ef9cb200 ee2c5550 00000003 00000000 ef871ee4 0041706e
[ 1687.358729] Call Trace:
[ 1687.358729] [<b02e3b7f>] io_schedule+0x4f/0x89
[ 1687.358729] [<b01a287d>] sync_buffer+0x30/0x34
[ 1687.358729] [<b02e3d8f>] __wait_on_bit+0x42/0x5e
[ 1687.358729] [<b01a284d>] sync_buffer+0x0/0x34
[ 1687.358729] [<b02e3e12>] out_of_line_wait_on_bit+0x67/0x6f
[ 1687.358729] [<b01a284d>] sync_buffer+0x0/0x34
[ 1687.358729] [<b013e1dd>] wake_bit_function+0x0/0x3c
[ 1687.358729] [<b01a2814>] __wait_on_buffer+0x24/0x29
[ 1687.358729] [<b01a4225>] __bread+0x55/0x8a
[ 1687.358729] [<f0d5e865>] ext2_get_inode+0xbe/0x109 [ext2]
[ 1687.358729] [<f0d5e8e9>] ext2_update_inode+0x39/0x331 [ext2]
[ 1687.358729] [<b01a8a5e>] mpage_bio_submit+0x19/0x1d
[ 1687.358729] [<f0d5f530>] ext2_get_block+0x0/0x761 [ext2]
[ 1687.358729] [<b019dd1c>] __writeback_single_inode+0x228/0x306
[ 1687.358729] [<b0104bf8>] apic_timer_interrupt+0x28/0x30
[ 1687.358729] [<b01e6005>] _atomic_dec_and_lock+0x31/0x5c
[ 1687.358729] [<b019e1a2>] sync_sb_inodes+0x1c3/0x294
[ 1687.358729] [<b019e450>] writeback_inodes+0x7d/0xac
[ 1687.358729] [<b016a086>] background_writeout+0x98/0xb7
[ 1687.358729] [<b016a56c>] pdflush+0x0/0x1d4
[ 1687.358730] [<b016a673>] pdflush+0x107/0x1d4
[ 1687.358730] [<b0169fee>] background_writeout+0x0/0xb7
[ 1687.358730] [<b013df26>] kthread+0x34/0x56
[ 1687.358730] [<b013def2>] kthread+0x0/0x56
[ 1687.358730] [<b0104d7b>] kernel_thread_helper+0x7/0x1c
[ 1687.358730] =======================
[ 1687.358730] hald-addon-st D ee990bc0 0 2330 2284
[ 1687.358730] ee990bd4 00000082 00000002 ee990bc0 ee990bb8 00000000 00000000 8334c2ad
[ 1687.358730] 00000273 b180c300 b040d300 b040d300 ee21c8b0 ee21cafc b180c300 ee990000
[ 1687.358730] ee990be8 00000000 ee398740 00248b9d ee2c5550 ee2c5550 00000000 00000003
[ 1687.358730] Call Trace:
[ 1687.358730] [<b02e3c23>] schedule_timeout+0x69/0xa1
[ 1687.358730] [<f084c7b4>] scsi_request_fn+0x210/0x351 [scsi_mod]
[ 1687.358730] [<b0135051>] del_timer+0x52/0x5a
[ 1687.358730] [<b01e4f7b>] cfq_set_request+0xc2/0x2ff
[ 1687.358730] [<b02e30a7>] wait_for_common+0x6a/0x101
[ 1687.358730] [<b0121b63>] default_wake_function+0x0/0xc
[ 1687.358730] [<b01dc611>] blk_execute_rq+0x72/0xb3
[ 1687.358730] [<b01db42e>] blk_end_sync_rq+0x0/0x23
[ 1687.358730] [<b0121b63>] default_wake_function+0x0/0xc
[ 1687.358730] [<b01dc702>] get_request_wait+0x1b/0x173
[ 1687.358730] [<f084c089>] scsi_execute+0xc7/0xdb [scsi_mod]
[ 1687.358730] [<f084c10a>] scsi_execute_req+0x6d/0xd0 [scsi_mod]
[ 1687.358730] [<f084c1c3>] scsi_test_unit_ready+0x56/0x95 [scsi_mod]
[ 1687.358730] [<f0b060da>] sr_media_change+0x3a/0x223 [sr_mod]
[ 1687.358730] [<f0b07557>] sr_drive_status+0x53/0x65 [sr_mod]
[ 1687.358730] [<f084c1c3>] scsi_test_unit_ready+0x56/0x95 [scsi_mod]
[ 1687.358730] [<f0ae1074>] media_changed+0x47/0x7e [cdrom]
[ 1687.358730] [<f0ae45f2>] cdrom_ioctl+0x275/0xdca [cdrom]
[ 1687.358730] [<b018c5e7>] __link_path_walk+0x9ea/0xd06
[ 1687.358730] [<f0ae1074>] media_changed+0x47/0x7e [cdrom]
[ 1687.358730] [<f0b07077>] sr_block_ioctl+0x47/0x80 [sr_mod]
[ 1687.358730] [<b01ddd7f>] blkdev_driver_ioctl+0x55/0x5e
[ 1687.358730] [<b01ddf9f>] blkdev_ioctl+0x217/0x7c8
[ 1687.358730] [<b0181f91>] get_unused_fd_flags+0xb5/0xce
[ 1687.358730] [<b01e6d72>] kobject_get+0xf/0x13
[ 1687.358730] [<b01de96d>] get_disk+0x1b/0x80
[ 1687.358730] [<b01de9d9>] exact_lock+0x7/0xd
[ 1687.358730] [<b02527df>] kobj_lookup+0x157/0x172
[ 1687.358730] [<b01e6d72>] kobject_get+0xf/0x13
[ 1687.358730] [<f0b063a1>] sr_block_open+0x70/0x81 [sr_mod]
[ 1687.358730] [<b01a6c34>] do_open+0xb5/0x28b
[ 1687.358730] [<b01a6fd4>] blkdev_open+0x25/0x53
[ 1687.358730] [<b0182130>] __dentry_open+0x17f/0x1d9
[ 1687.358730] [<b0182217>] nameidata_to_filp+0x31/0x3a
[ 1687.358730] [<b01a6faf>] blkdev_open+0x0/0x53
[ 1687.358730] [<b0182259>] do_filp_open+0x39/0x40
[ 1687.358730] [<b011c0f6>] check_pgt_cache+0x1b/0x1f
[ 1687.358730] [<b01a6414>] block_ioctl+0x18/0x1d
[ 1687.358730] [<b01a63fc>] block_ioctl+0x0/0x1d
[ 1687.358730] [<b018ea4f>] do_ioctl+0x1f/0x6d
[ 1687.358730] [<b018eca0>] vfs_ioctl+0x203/0x27f
[ 1687.358730] [<b018230b>] do_sys_open+0xab/0xc0
[ 1687.358730] [<b018ed72>] sys_ioctl+0x56/0x68
[ 1687.358730] [<b010412a>] sysenter_past_esp+0x5f/0x85
[ 1687.358730] =======================
[ 1687.358730] cp D b011fcc6 0 4301 3844
[ 1687.358730] cc4b4b94 00200082 b180c300 b011fcc6 30cf0ee6 00000008 00000000 00000000
[ 1687.358730] b0d3bb7a 00000188 b040d300 b040d300 ee1b18f0 ee1b1b3c b180c300 cc4b4000
[ 1687.358730] b1809a40 ee2c5550 edd57740 ee2c5550 00000004 00000000 ef824558 0041706e
[ 1687.358730] Call Trace:
[ 1687.358730] [<b011fcc6>] hrtick_start_fair+0xa8/0x150
[ 1687.358730] [<b02e3b7f>] io_schedule+0x4f/0x89
[ 1687.358730] [<b01a287d>] sync_buffer+0x30/0x34
[ 1687.358730] [<b02e3cbc>] __wait_on_bit_lock+0x3d/0x5f
[ 1687.358730] [<b01a284d>] sync_buffer+0x0/0x34
[ 1687.358730] [<b02e3d45>] out_of_line_wait_on_bit_lock+0x67/0x6f
[ 1687.358730] [<b01a284d>] sync_buffer+0x0/0x34
[ 1687.358730] [<b013e1dd>] wake_bit_function+0x0/0x3c
[ 1687.358730] [<b01a2a1b>] __lock_buffer+0x29/0x2e
[ 1687.358730] [<b01a4247>] __bread+0x77/0x8a
[ 1687.358730] [<f0d5e865>] ext2_get_inode+0xbe/0x109 [ext2]
[ 1687.358730] [<f0d5e8e9>] ext2_update_inode+0x39/0x331 [ext2]
[ 1687.358730] [<b01a8a5e>] mpage_bio_submit+0x19/0x1d
[ 1687.358730] [<f0d5f530>] ext2_get_block+0x0/0x761 [ext2]
[ 1687.358730] [<b019dd1c>] __writeback_single_inode+0x228/0x306
[ 1687.358730] [<b01e6005>] _atomic_dec_and_lock+0x31/0x5c
[ 1687.358730] [<b019e1a2>] sync_sb_inodes+0x1c3/0x294
[ 1687.358730] [<b019e450>] writeback_inodes+0x7d/0xac
[ 1687.358730] [<b0169dd5>] balance_dirty_pages_ratelimited_nr+0x21f/0x33f
[ 1687.358730] [<b0164773>] generic_file_buffered_write+0x1c1/0x655
[ 1687.358730] [<f0a5a5df>] ext3_readpages+0x0/0x15 [ext3]
[ 1687.358730] [<b0164eb4>] __generic_file_aio_write_nolock+0x2ad/0x50d
[ 1687.358730] [<b0130667>] current_fs_time+0x13/0x15
[ 1687.358730] [<b0165179>] generic_file_aio_write+0x65/0xd3
[ 1687.358730] [<b01836ef>] do_sync_write+0xd2/0x10e
[ 1687.358730] [<b0146d22>] tick_sched_timer+0x0/0xbf
[ 1687.358730] [<b013e1a8>] autoremove_wake_function+0x0/0x35
[ 1687.358730] [<b018361d>] do_sync_write+0x0/0x10e
[ 1687.358730] [<b0183f2f>] vfs_write+0xa4/0x14a
[ 1687.358730] [<b0184556>] sys_write+0x41/0x6a
[ 1687.358730] [<b010412a>] sysenter_past_esp+0x5f/0x85
[ 1687.358730] =======================
[ 1687.358730] bonnie D eee95dcc 0 5328 3749
[ 1687.358730] eee95de0 00200086 00000002 eee95dcc eee95dc4 00000000 00000000 b0145bda
[ 1687.358730] 3c876200 eee95da8 b040d300 b040d300 e16c2470 e16c26bc b180c300 eee95000
[ 1687.358730] 000004b3 ee2c5550 edd573c0 0024876a b01dc8d2 b01436cd 00000000 00000003
[ 1687.358730] Call Trace:
[ 1687.358730] [<b0145bda>] clockevents_program_event+0x9a/0x12e
[ 1687.358730] [<b01dc8d2>] generic_unplug_device+0x15/0x21
[ 1687.358730] [<b01436cd>] getnstimeofday+0x2f/0xd7
[ 1687.358730] [<b02e3b7f>] io_schedule+0x4f/0x89
[ 1687.358730] [<b01a287d>] sync_buffer+0x30/0x34
[ 1687.358730] [<b02e3cbc>] __wait_on_bit_lock+0x3d/0x5f
[ 1687.358730] [<b01a284d>] sync_buffer+0x0/0x34
[ 1687.358730] [<b02e3d45>] out_of_line_wait_on_bit_lock+0x67/0x6f
[ 1687.358730] [<b01a284d>] sync_buffer+0x0/0x34
[ 1687.358730] [<b013e1dd>] wake_bit_function+0x0/0x3c
[ 1687.358730] [<b01a2a1b>] __lock_buffer+0x29/0x2e
[ 1687.358730] [<b01a4247>] __bread+0x77/0x8a
[ 1687.358730] [<f0d5e865>] ext2_get_inode+0xbe/0x109 [ext2]
[ 1687.358730] [<f0d5e8e9>] ext2_update_inode+0x39/0x331 [ext2]
[ 1687.358730] [<b01a8a5e>] mpage_bio_submit+0x19/0x1d
[ 1687.358730] [<f0d5f530>] ext2_get_block+0x0/0x761 [ext2]
[ 1687.358730] [<b019dd1c>] __writeback_single_inode+0x228/0x306
[ 1687.358730] [<b01633b8>] find_get_pages_tag+0x75/0x84
[ 1687.358730] [<b0104b68>] reschedule_interrupt+0x28/0x30
[ 1687.358730] [<b01e6005>] _atomic_dec_and_lock+0x31/0x5c
[ 1687.358730] [<b019e1a2>] sync_sb_inodes+0x1c3/0x294
[ 1687.358730] [<b019e2f1>] sync_inodes_sb+0x7e/0x8f
[ 1687.358730] [<b019e378>] __sync_inodes+0x76/0xa5
[ 1687.358730] [<b019e3b8>] sync_inodes+0x11/0x2c
[ 1687.358730] [<b01a0c7a>] do_sync+0x14/0x63
[ 1687.358730] [<b01a0cd3>] sys_sync+0xa/0x17
[ 1687.358730] [<b010412a>] sysenter_past_esp+0x5f/0x85
[ 1687.358730] =======================
[ 1687.358730] pdflush D ee25dee0 0 14924 2
[ 1687.358730] ee25def4 00000046 00000002 ee25dee0 ee25ded8 00000000 00000000 b03a53c0
[ 1687.358730] aadc0469 00000188 b040d300 b040d300 dc20ce30 dc20d07c b180c300 ee25d000
[ 1687.358730] 00000202 b0443e00 ee244c80 002491c9 ee25df04 b0134a01 ffffffff 00000003
[ 1687.358730] Call Trace:
[ 1687.358730] [<b0134a01>] process_timeout+0x0/0x5
[ 1687.358730] [<b02e3bfe>] schedule_timeout+0x44/0xa1
[ 1687.358730] [<b0134a01>] process_timeout+0x0/0x5
[ 1687.358730] [<b02e3bf9>] schedule_timeout+0x3f/0xa1
[ 1687.358730] [<b02e3a81>] io_schedule_timeout+0x54/0x93
[ 1687.358730] [<b016edcf>] congestion_wait+0x4d/0x61
[ 1687.358730] [<b013e1a8>] autoremove_wake_function+0x0/0x35
[ 1687.358730] [<b016a16b>] wb_kupdate+0x9c/0xe2
[ 1687.358730] [<b016a56c>] pdflush+0x0/0x1d4
[ 1687.358730] [<b016a673>] pdflush+0x107/0x1d4
[ 1687.358730] [<b016a0cf>] wb_kupdate+0x0/0xe2
[ 1687.358730] [<b013df26>] kthread+0x34/0x56
[ 1687.358730] [<b013def2>] kthread+0x0/0x56
[ 1687.358730] [<b0104d7b>] kernel_thread_helper+0x7/0x1c
[ 1687.358730] =======================
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-07 5:33 ` Mike Galbraith
@ 2008-01-07 5:55 ` Mike Galbraith
0 siblings, 0 replies; 16+ messages in thread
From: Mike Galbraith @ 2008-01-07 5:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML
> [ 1687.358730] [<b01a0cd3>] sys_sync+0xa/0x17
duh.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-06 20:29 ` Andrew Morton
2008-01-07 5:33 ` Mike Galbraith
@ 2008-01-08 11:05 ` Mike Galbraith
2008-01-08 11:38 ` Andrew Morton
1 sibling, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-08 11:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML
On Sun, 2008-01-06 at 12:29 -0800, Andrew Morton wrote:
> On Sun, 06 Jan 2008 19:01:10 +0100 Mike Galbraith <efault@gmx.de> wrote:
>
> >
> > On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> > > FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
> >
> > Ugh, horrid device IO ==> horrid VM AFIKT. I'll continue rummaging, but
> > I wonder, am I doing something _so_ stupid as to warrant zero response?
> >
>
> Copying linux-mm might have helped. Bad time of year, too.
>
> >From the traces it looks like all IO has stopped and everyone is waiting
> (directly or indirectly) for certain IO completions. Is that really true,
> or is IO still dribbling along?
>
> >From the kswapd0 trace it would appear that UDF is doing synchronous writes
> (udf_update_inode->sync_dirty_buffer) which perhaps is making things
> mightily slow.
This is a pretty uninteresting thread except for the VM aspect, but
rather than leave it dangling, I'll laugh at my naivety and close.
Seeks on DVD drives are apparently far FAR more horrible that I ever
imagined, so writing to a filesystem on a DVD+RW in effect constitutes
the stupid thing I was worried about above. Make an image, populate it,
write it instead... sure to be a truckload faster, and due to the VM
connection, much safer too. Oh well.
EOT
-Mike
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-08 11:05 ` Mike Galbraith
@ 2008-01-08 11:38 ` Andrew Morton
2008-01-08 15:21 ` Mike Galbraith
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Morton @ 2008-01-08 11:38 UTC (permalink / raw)
To: Mike Galbraith; +Cc: LKML
On Tue, 08 Jan 2008 12:05:16 +0100 Mike Galbraith <efault@gmx.de> wrote:
>
> On Sun, 2008-01-06 at 12:29 -0800, Andrew Morton wrote:
> > On Sun, 06 Jan 2008 19:01:10 +0100 Mike Galbraith <efault@gmx.de> wrote:
> >
> > >
> > > On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> > > > FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
> > >
> > > Ugh, horrid device IO ==> horrid VM AFIKT. I'll continue rummaging, but
> > > I wonder, am I doing something _so_ stupid as to warrant zero response?
> > >
> >
> > Copying linux-mm might have helped. Bad time of year, too.
> >
> > >From the traces it looks like all IO has stopped and everyone is waiting
> > (directly or indirectly) for certain IO completions. Is that really true,
> > or is IO still dribbling along?
> >
> > >From the kswapd0 trace it would appear that UDF is doing synchronous writes
> > (udf_update_inode->sync_dirty_buffer) which perhaps is making things
> > mightily slow.
>
> This is a pretty uninteresting thread except for the VM aspect, but
> rather than leave it dangling, I'll laugh at my naivety and close.
>
> Seeks on DVD drives are apparently far FAR more horrible that I ever
> imagined, so writing to a filesystem on a DVD+RW in effect constitutes
> the stupid thing I was worried about above. Make an image, populate it,
> write it instead... sure to be a truckload faster, and due to the VM
> connection, much safer too. Oh well.
>
Well. From your earlier trace it appeared that something was causing
the filesystem to perform synchronous inode writes - sync_dirty_buffer() was
called.
This will cause many more seeks than would occur if we were doing full
delayed writing, with obvious throughput implications.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-08 11:38 ` Andrew Morton
@ 2008-01-08 15:21 ` Mike Galbraith
2008-01-08 15:27 ` Mike Galbraith
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-08 15:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML
On Tue, 2008-01-08 at 03:38 -0800, Andrew Morton wrote:
> On Tue, 08 Jan 2008 12:05:16 +0100 Mike Galbraith <efault@gmx.de> wrote:
> > Seeks on DVD drives are apparently far FAR more horrible that I ever
> > imagined, so writing to a filesystem on a DVD+RW in effect constitutes
> > the stupid thing I was worried about above. Make an image, populate it,
> > write it instead... sure to be a truckload faster, and due to the VM
> > connection, much safer too. Oh well.
> >
>
> Well. From your earlier trace it appeared that something was causing
> the filesystem to perform synchronous inode writes - sync_dirty_buffer() was
> called.
>
> This will cause many more seeks than would occur if we were doing full
> delayed writing, with obvious throughput implications.
Yes, with UDF, the IO was _incredibly_ slow. With ext2, it was better,
though still very bad. I tested with that other OS, and it gets ~same
throughput with UDF as I got with ext2 (ick).
UDF does udf_clear_inode() -> write_inode_now(inode, 1)
I suppose I could try write_inode_now(inode, 0). Might unstick the box.
-Mike
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-08 15:21 ` Mike Galbraith
@ 2008-01-08 15:27 ` Mike Galbraith
2008-01-09 11:11 ` Mike Galbraith
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-08 15:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML
On Tue, 2008-01-08 at 16:21 +0100, Mike Galbraith wrote:
> On Tue, 2008-01-08 at 03:38 -0800, Andrew Morton wrote:
> >
> > Well. From your earlier trace it appeared that something was causing
> > the filesystem to perform synchronous inode writes - sync_dirty_buffer() was
> > called.
> >
> > This will cause many more seeks than would occur if we were doing full
> > delayed writing, with obvious throughput implications.
>
> Yes, with UDF, the IO was _incredibly_ slow. With ext2, it was better,
> though still very bad. I tested with that other OS, and it gets ~same
> throughput with UDF as I got with ext2 (ick).
>
> UDF does udf_clear_inode() -> write_inode_now(inode, 1)
>
> I suppose I could try write_inode_now(inode, 0). Might unstick the box.
(nope, still sync, UDF still deadly)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-08 15:27 ` Mike Galbraith
@ 2008-01-09 11:11 ` Mike Galbraith
2008-01-09 23:01 ` Andrew Morton
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-09 11:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML, linux-mm
On Tue, 2008-01-08 at 16:27 +0100, Mike Galbraith wrote:
> On Tue, 2008-01-08 at 16:21 +0100, Mike Galbraith wrote:
> > On Tue, 2008-01-08 at 03:38 -0800, Andrew Morton wrote:
> > >
> > > Well. From your earlier trace it appeared that something was causing
> > > the filesystem to perform synchronous inode writes - sync_dirty_buffer() was
> > > called.
> > >
> > > This will cause many more seeks than would occur if we were doing full
> > > delayed writing, with obvious throughput implications.
> >
> > Yes, with UDF, the IO was _incredibly_ slow. With ext2, it was better,
> > though still very bad. I tested with that other OS, and it gets ~same
> > throughput with UDF as I got with ext2 (ick).
> >
> > UDF does udf_clear_inode() -> write_inode_now(inode, 1)
> >
> > I suppose I could try write_inode_now(inode, 0). Might unstick the box.
>
> (nope, still sync, UDF still deadly)
write_inode_now() is a fibber.
The below seems to fix it in that writes dribbling to the DVD+RW at the
whopping 1 to 10 pages/sec I'm seeing no longer turn box into a
doorstop. It's probably busted as heck.
Think I'll cc linux-mm, and go find something safer to play with.
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 0fca820..f1cce24 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -657,7 +657,7 @@ int write_inode_now(struct inode *inode, int sync)
int ret;
struct writeback_control wbc = {
.nr_to_write = LONG_MAX,
- .sync_mode = WB_SYNC_ALL,
+ .sync_mode = sync ? WB_SYNC_ALL : WB_SYNC_NONE,
.range_start = 0,
.range_end = LLONG_MAX,
};
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 6ff8151..d1fc116 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -117,7 +117,7 @@ void udf_clear_inode(struct inode *inode)
udf_discard_prealloc(inode);
udf_truncate_tail_extent(inode);
unlock_kernel();
- write_inode_now(inode, 1);
+ write_inode_now(inode, 0);
}
kfree(UDF_I_DATA(inode));
UDF_I_DATA(inode) = NULL;
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-09 11:11 ` Mike Galbraith
@ 2008-01-09 23:01 ` Andrew Morton
2008-01-10 4:21 ` Mike Galbraith
2008-01-10 14:41 ` Jan Kara
0 siblings, 2 replies; 16+ messages in thread
From: Andrew Morton @ 2008-01-09 23:01 UTC (permalink / raw)
To: Mike Galbraith; +Cc: linux-kernel, linux-mm
On Wed, 09 Jan 2008 12:11:20 +0100
Mike Galbraith <efault@gmx.de> wrote:
>
> On Tue, 2008-01-08 at 16:27 +0100, Mike Galbraith wrote:
> > On Tue, 2008-01-08 at 16:21 +0100, Mike Galbraith wrote:
> > > On Tue, 2008-01-08 at 03:38 -0800, Andrew Morton wrote:
> > > >
> > > > Well. From your earlier trace it appeared that something was causing
> > > > the filesystem to perform synchronous inode writes - sync_dirty_buffer() was
> > > > called.
> > > >
> > > > This will cause many more seeks than would occur if we were doing full
> > > > delayed writing, with obvious throughput implications.
> > >
> > > Yes, with UDF, the IO was _incredibly_ slow. With ext2, it was better,
> > > though still very bad. I tested with that other OS, and it gets ~same
> > > throughput with UDF as I got with ext2 (ick).
> > >
> > > UDF does udf_clear_inode() -> write_inode_now(inode, 1)
> > >
> > > I suppose I could try write_inode_now(inode, 0). Might unstick the box.
> >
> > (nope, still sync, UDF still deadly)
>
> write_inode_now() is a fibber.
Sure is. Looks like it was busted by:
commit fa94396d2792f5093aab7cf66e1fc1da0c9fc442
Author: akpm <akpm>
Date: Tue Feb 4 17:01:43 2003 +0000
[PATCH] Remove unneeded code in fs/fs-writeback.c
We do not need to pass the `wait' argument down to __sync_single_inode().
That information is now present at wbc->sync_mode.
> The below seems to fix it in that writes dribbling to the DVD+RW at the
> whopping 1 to 10 pages/sec I'm seeing no longer turn box into a
> doorstop. It's probably busted as heck.
The VFS change looks good. Not sure about the UDF details.
> Think I'll cc linux-mm, and go find something safer to play with.
>
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 0fca820..f1cce24 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -657,7 +657,7 @@ int write_inode_now(struct inode *inode, int sync)
> int ret;
> struct writeback_control wbc = {
> .nr_to_write = LONG_MAX,
> - .sync_mode = WB_SYNC_ALL,
> + .sync_mode = sync ? WB_SYNC_ALL : WB_SYNC_NONE,
> .range_start = 0,
> .range_end = LLONG_MAX,
> };
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index 6ff8151..d1fc116 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -117,7 +117,7 @@ void udf_clear_inode(struct inode *inode)
> udf_discard_prealloc(inode);
> udf_truncate_tail_extent(inode);
> unlock_kernel();
> - write_inode_now(inode, 1);
> + write_inode_now(inode, 0);
> }
> kfree(UDF_I_DATA(inode));
> UDF_I_DATA(inode) = NULL;
>
WB_SYNC_* should die.
I wonder why UDF was doing a synchronous write in there. In fact I wonder
why it's writing the inode at all? extN doesn't do that. If for some
reason it really does want to make the inode immediately reclaimable then
simply shoving it down into the /dev/hda1 pagecache should be sufficient
(ie: what you did)..
hm.
So are you saying that the fs throughput is unaltered by this change,
but that the side-effects which your workload has on the overall
machine are lessened?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-09 23:01 ` Andrew Morton
@ 2008-01-10 4:21 ` Mike Galbraith
2008-01-10 14:41 ` Jan Kara
1 sibling, 0 replies; 16+ messages in thread
From: Mike Galbraith @ 2008-01-10 4:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm, bfennema
On Wed, 2008-01-09 at 15:01 -0800, Andrew Morton wrote:
> So are you saying that the fs throughput is unaltered by this change,
> but that the side-effects which your workload has on the overall
> machine are lessened?
Yes. UDF IO is still a slow trickle, but the box is now fine under VM
stress, vs all allocating tasks eventually getting nailed (essentially
forever) by iprune_mutex previously.
-Mike
P.S. I would submit one-liner for VFS part, but it's useless without
UDF part, and nobody is hitting what I ran into while testing alleged
scsi_done regression thingy anyway. cc added.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-09 23:01 ` Andrew Morton
2008-01-10 4:21 ` Mike Galbraith
@ 2008-01-10 14:41 ` Jan Kara
2008-01-10 15:29 ` Mike Galbraith
1 sibling, 1 reply; 16+ messages in thread
From: Jan Kara @ 2008-01-10 14:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Mike Galbraith, linux-kernel, linux-mm
> On Wed, 09 Jan 2008 12:11:20 +0100
> Mike Galbraith <efault@gmx.de> wrote:
>
> >
> > On Tue, 2008-01-08 at 16:27 +0100, Mike Galbraith wrote:
> > > On Tue, 2008-01-08 at 16:21 +0100, Mike Galbraith wrote:
> > > > On Tue, 2008-01-08 at 03:38 -0800, Andrew Morton wrote:
> > > > >
> > > > > Well. From your earlier trace it appeared that something was causing
> > > > > the filesystem to perform synchronous inode writes - sync_dirty_buffer() was
> > > > > called.
> > > > >
> > > > > This will cause many more seeks than would occur if we were doing full
> > > > > delayed writing, with obvious throughput implications.
> > > >
> > > > Yes, with UDF, the IO was _incredibly_ slow. With ext2, it was better,
> > > > though still very bad. I tested with that other OS, and it gets ~same
> > > > throughput with UDF as I got with ext2 (ick).
> > > >
> > > > UDF does udf_clear_inode() -> write_inode_now(inode, 1)
> > > >
> > > > I suppose I could try write_inode_now(inode, 0). Might unstick the box.
> > >
> > > (nope, still sync, UDF still deadly)
> >
> > write_inode_now() is a fibber.
>
> Sure is. Looks like it was busted by:
>
> commit fa94396d2792f5093aab7cf66e1fc1da0c9fc442
> Author: akpm <akpm>
> Date: Tue Feb 4 17:01:43 2003 +0000
>
> [PATCH] Remove unneeded code in fs/fs-writeback.c
>
> We do not need to pass the `wait' argument down to __sync_single_inode().
> That information is now present at wbc->sync_mode.
>
>
> > The below seems to fix it in that writes dribbling to the DVD+RW at the
> > whopping 1 to 10 pages/sec I'm seeing no longer turn box into a
> > doorstop. It's probably busted as heck.
>
> The VFS change looks good. Not sure about the UDF details.
>
> > Think I'll cc linux-mm, and go find something safer to play with.
> >
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index 0fca820..f1cce24 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -657,7 +657,7 @@ int write_inode_now(struct inode *inode, int sync)
> > int ret;
> > struct writeback_control wbc = {
> > .nr_to_write = LONG_MAX,
> > - .sync_mode = WB_SYNC_ALL,
> > + .sync_mode = sync ? WB_SYNC_ALL : WB_SYNC_NONE,
> > .range_start = 0,
> > .range_end = LLONG_MAX,
> > };
> > diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> > index 6ff8151..d1fc116 100644
> > --- a/fs/udf/inode.c
> > +++ b/fs/udf/inode.c
> > @@ -117,7 +117,7 @@ void udf_clear_inode(struct inode *inode)
> > udf_discard_prealloc(inode);
> > udf_truncate_tail_extent(inode);
> > unlock_kernel();
> > - write_inode_now(inode, 1);
> > + write_inode_now(inode, 0);
> > }
> > kfree(UDF_I_DATA(inode));
> > UDF_I_DATA(inode) = NULL;
> >
>
> WB_SYNC_* should die.
>
> I wonder why UDF was doing a synchronous write in there. In fact I wonder
> why it's writing the inode at all? extN doesn't do that. If for some
> reason it really does want to make the inode immediately reclaimable then
> simply shoving it down into the /dev/hda1 pagecache should be sufficient
> (ie: what you did)..
Looking at the code, I think UDF change is correct. UDF has to call
write_inode_now() because by the time clear_inode() is called, inode is
already written by VFS and prepared to be freed. But then UDF modifies
it in udf_clear_inode() (removes preallocation) and for these changes to
get to disk you have to write the inode explicitely.
But there's really no need to wait on IO. We only have to copy all
data from inode structure into buffers and that happens even if we don't
wait on sync.
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-10 14:41 ` Jan Kara
@ 2008-01-10 15:29 ` Mike Galbraith
2008-01-10 17:16 ` Jan Kara
0 siblings, 1 reply; 16+ messages in thread
From: Mike Galbraith @ 2008-01-10 15:29 UTC (permalink / raw)
To: Jan Kara; +Cc: Andrew Morton, linux-kernel, linux-mm, bfennema
On Thu, 2008-01-10 at 15:41 +0100, Jan Kara wrote:
> > On Wed, 09 Jan 2008 12:11:20 +0100
> >
> >
> > I wonder why UDF was doing a synchronous write in there. In fact I wonder
> > why it's writing the inode at all? extN doesn't do that. If for some
> > reason it really does want to make the inode immediately reclaimable then
> > simply shoving it down into the /dev/hda1 pagecache should be sufficient
> > (ie: what you did)..
> Looking at the code, I think UDF change is correct. UDF has to call
> write_inode_now() because by the time clear_inode() is called, inode is
> already written by VFS and prepared to be freed. But then UDF modifies
> it in udf_clear_inode() (removes preallocation) and for these changes to
> get to disk you have to write the inode explicitely.
> But there's really no need to wait on IO. We only have to copy all
> data from inode structure into buffers and that happens even if we don't
> wait on sync.
Perhaps I should go ahead and submit it then. There are 5 other async
callers as well, so VM/UDF reclaim buglet can die, and those others can
get what they asked for with net diffstat of 0.
Fix udf_clear_inode() to request asynchronous writeout in icache reclaim
path, and ensure that write_inore_now() honors that request, lest
allocators needlessly block on iprune_mutex.
Signed-off-by: Mike Galbraith <efault@gmx.de>
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 0fca820..f1cce24 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -657,7 +657,7 @@ int write_inode_now(struct inode *inode, int sync)
int ret;
struct writeback_control wbc = {
.nr_to_write = LONG_MAX,
- .sync_mode = WB_SYNC_ALL,
+ .sync_mode = sync ? WB_SYNC_ALL : WB_SYNC_NONE,
.range_start = 0,
.range_end = LLONG_MAX,
};
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 6ff8151..d1fc116 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -117,7 +117,7 @@ void udf_clear_inode(struct inode *inode)
udf_discard_prealloc(inode);
udf_truncate_tail_extent(inode);
unlock_kernel();
- write_inode_now(inode, 1);
+ write_inode_now(inode, 0);
}
kfree(UDF_I_DATA(inode));
UDF_I_DATA(inode) = NULL;
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop
2008-01-10 15:29 ` Mike Galbraith
@ 2008-01-10 17:16 ` Jan Kara
0 siblings, 0 replies; 16+ messages in thread
From: Jan Kara @ 2008-01-10 17:16 UTC (permalink / raw)
To: Mike Galbraith; +Cc: Andrew Morton, linux-kernel, linux-mm, bfennema
On Thu 10-01-08 16:29:50, Mike Galbraith wrote:
>
> On Thu, 2008-01-10 at 15:41 +0100, Jan Kara wrote:
> > > On Wed, 09 Jan 2008 12:11:20 +0100
> > >
> > >
> > > I wonder why UDF was doing a synchronous write in there. In fact I wonder
> > > why it's writing the inode at all? extN doesn't do that. If for some
> > > reason it really does want to make the inode immediately reclaimable then
> > > simply shoving it down into the /dev/hda1 pagecache should be sufficient
> > > (ie: what you did)..
> > Looking at the code, I think UDF change is correct. UDF has to call
> > write_inode_now() because by the time clear_inode() is called, inode is
> > already written by VFS and prepared to be freed. But then UDF modifies
> > it in udf_clear_inode() (removes preallocation) and for these changes to
> > get to disk you have to write the inode explicitely.
> > But there's really no need to wait on IO. We only have to copy all
> > data from inode structure into buffers and that happens even if we don't
> > wait on sync.
>
> Perhaps I should go ahead and submit it then. There are 5 other async
> callers as well, so VM/UDF reclaim buglet can die, and those others can
> get what they asked for with net diffstat of 0.
>
> Fix udf_clear_inode() to request asynchronous writeout in icache reclaim
> path, and ensure that write_inore_now() honors that request, lest
> allocators needlessly block on iprune_mutex.
>
> Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Jan Kara <jack@suse.cz>
if it's worth anything ;)
Honza
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 0fca820..f1cce24 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -657,7 +657,7 @@ int write_inode_now(struct inode *inode, int sync)
> int ret;
> struct writeback_control wbc = {
> .nr_to_write = LONG_MAX,
> - .sync_mode = WB_SYNC_ALL,
> + .sync_mode = sync ? WB_SYNC_ALL : WB_SYNC_NONE,
> .range_start = 0,
> .range_end = LLONG_MAX,
> };
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index 6ff8151..d1fc116 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -117,7 +117,7 @@ void udf_clear_inode(struct inode *inode)
> udf_discard_prealloc(inode);
> udf_truncate_tail_extent(inode);
> unlock_kernel();
> - write_inode_now(inode, 1);
> + write_inode_now(inode, 0);
> }
> kfree(UDF_I_DATA(inode));
> UDF_I_DATA(inode) = NULL;
>
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2008-01-10 17:16 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-04 11:46 [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop Mike Galbraith
2008-01-06 9:42 ` Mike Galbraith
2008-01-06 18:01 ` Mike Galbraith
2008-01-06 20:29 ` Andrew Morton
2008-01-07 5:33 ` Mike Galbraith
2008-01-07 5:55 ` Mike Galbraith
2008-01-08 11:05 ` Mike Galbraith
2008-01-08 11:38 ` Andrew Morton
2008-01-08 15:21 ` Mike Galbraith
2008-01-08 15:27 ` Mike Galbraith
2008-01-09 11:11 ` Mike Galbraith
2008-01-09 23:01 ` Andrew Morton
2008-01-10 4:21 ` Mike Galbraith
2008-01-10 14:41 ` Jan Kara
2008-01-10 15:29 ` Mike Galbraith
2008-01-10 17:16 ` Jan Kara
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).