search for: wake_up_bit

We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.

...lone.21+0xba/0x1a0 [btrfs] [ 5472.099971] [<ffffffff815db96e>] ? _raw_spin_lock+0xe/0x20 [ 5472.099997] [<ffffffffa003966f>] btrfs_commit_transaction+0x3ef/0x870 [btrfs] [ 5472.100065] [<ffffffff81012871>] ? __switch_to+0x261/0x2f0 [ 5472.100084] [<ffffffff81086bf0>] ? wake_up_bit+0x40/0x40 [ 5472.100120] [<ffffffffa0039af0>] ? btrfs_commit_transaction+0x870/0x870 [btrfs] [ 5472.100155] [<ffffffffa0039b0f>] do_async_commit+0x1f/0x30 [btrfs] [ 5472.100171] [<ffffffff8108110d>] process_one_work+0x11d/0x430 [ 5472.100187] [<ffffffff81081c69>] worker...

...t kernel: [<ffffffff8006a3c2>] do_IRQ+0xec/0xf5 Jan 8 05:20:00 localhost kernel: [<ffffffff8005b615>] ret_from_intr+0x0/0xa Jan 8 05:20:00 localhost kernel: <EOI> [<ffffffff8000cb74>] bit_waitqueue+0x3c/0xb4 Jan 8 05:20:00 localhost kernel: [<ffffffff8002ce23>] wake_up_bit+0x11/0x22 Jan 8 05:20:00 localhost kernel: [<ffffffff880328ef>] :jbd:do_get_write_access+0x137/0x527 Jan 8 05:20:01 localhost kernel: [<ffffffff800192e9>] __getblk+0x25/0x22c Jan 8 05:20:01 localhost kernel: [<ffffffff88032d01>] :jbd:journal_get_write_access+0x22/0x33 Jan 8...

...ffffffffa02e9fd6>] ? btrfs_run_delayed_refs+0xd1/0x17c [btrfs] [<ffffffffa02f8467>] ? btrfs_commit_transaction+0x38f/0x709 [btrfs] [<ffffffff8136f6e6>] ? _raw_spin_lock+0xe/0x10 [<ffffffffa02f79fe>] ? join_transaction.clone.23+0xc1/0x200 [btrfs] [<ffffffff81068ffb>] ? wake_up_bit+0x2a/0x2a [<ffffffffa02f28fd>] ? transaction_kthread+0x175/0x22a [btrfs] [<ffffffffa02f2788>] ? btrfs_congested_fn+0x86/0x86 [btrfs] [<ffffffff81068b2c>] ? kthread+0x82/0x8a [<ffffffff81376124>] ? kernel_thread_helper+0x4/0x10 [<ffffffff81068aaa>] ? kthread_worker...

...ffffc900106c7ac0 Call Trace: [<ffffffff8141b06d>] notify_remote_via_irq+0xd/0x40 [<ffffffff81543b9b>] xen_netbk_rx_action+0x73b/0x800 [<ffffffff81544c25>] xen_netbk_kthread+0xb5/0xa60 [<ffffffff81080050>] ? finish_task_switch+0x60/0xd0 [<ffffffff81071fe0>] ? wake_up_bit+0x40/0x40 [<ffffffff81544b70>] ? xen_netbk_tx_build_gops+0xa10/0xa10 [<ffffffff81071926>] kthread+0xc6/0xd0 [<ffffffff810037b9>] ? xen_end_context_switch+0x19/0x20 [<ffffffff81071860>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff81767c7c>] ret_from_fo...

...24] [<ffffffffa0459983>] btrfs_write_dirty_block_groups+0x533/0x620 [btrfs] [ 68.128271] [<ffffffffa04676e2>] commit_cowonly_roots+0x172/0x260 [btrfs] [ 68.128314] [<ffffffffa04695ad>] btrfs_commit_transaction+0x5bd/0xaf0 [btrfs] [ 68.128353] [<ffffffff8107b460>] ? wake_up_bit+0x30/0x30 [ 68.128391] [<ffffffffa04a4edd>] btrfs_recover_log_trees+0x3bd/0x490 [btrfs] [ 68.128434] [<ffffffffa04a3270>] ? replay_one_dir_item+0xf0/0xf0 [btrfs] [ 68.128477] [<ffffffffa0466689>] open_ctree+0x17b9/0x1e80 [btrfs] [ 68.128513] [<ffffffff813555d3>]...

...+0xc4/0x1b0 [btrfs] [ 3924.297835] [<ffffffffa012cc1e>] btrfs_commit_transaction+0x3be/0x7e0 [btrfs] [ 3924.297840] [<ffffffff813fa0fb>] ? __schedule+0x2fb/0x940 [ 3924.297845] [<ffffffff810a1f20>] ? refresh_cpu_vm_stats+0x150/0x150 [ 3924.297849] [<ffffffff81052840>] ? wake_up_bit+0x40/0x40 [ 3924.297858] [<ffffffffa012d040>] ? btrfs_commit_transaction+0x7e0/0x7e0 [btrfs] [ 3924.297868] [<ffffffffa012d05a>] do_async_commit+0x1a/0x30 [btrfs] [ 3924.297873] [<ffffffff81350b70>] ? powersave_bias_target+0x170/0x170 [ 3924.297877] [<ffffffff8104e0bb>]...

...ernel: [<ffffffffa00e9dd8>] raid5d+0x1f8/0x350 [raid456] kernel: [<ffffffff8100a350>] ? xen_clocksource_read+0x20/0x30 kernel: [<ffffffff8156d23e>] ? _raw_spin_unlock_irqrestore+0x1e/0x30 kernel: [<ffffffff8144e5f7>] md_thread+0x117/0x150 kernel: [<ffffffff810789e0>] ? wake_up_bit+0x40/0x40 kernel: [<ffffffff8144e4e0>] ? md_rdev_init+0x110/0x110 kernel: [<ffffffff8107828e>] kthread+0xce/0xe0 kernel: [<ffffffff8100382e>] ? xen_end_context_switch+0x1e/0x30 kernel: [<ffffffff810781c0>] ? kthread_freezable_should_stop+0x70/0x70 kernel: [<ffffffff81575c...

...812e58cd>] device_unregister+0x1d/0x60 [ 1257.228914] [<ffffffff812b5a46>] xenbus_dev_changed+0x96/0x1b0 [ 1257.228920] [<ffffffff812b74b4>] frontend_changed+0x24/0x50 [ 1257.228926] [<ffffffff812b4221>] xenwatch_thread+0xb1/0x170 [ 1257.228933] [<ffffffff8106aea0>] ? wake_up_bit+0x40/0x40 [ 1257.228939] [<ffffffff812b4170>] ? xenbus_thread+0x40/0x40 [ 1257.228944] [<ffffffff8106a9a6>] kthread+0x96/0xa0 [ 1257.228951] [<ffffffff81465724>] kernel_thread_helper+0x4/0x10 [ 1257.228959] [<ffffffff8145c7fc>] ? retint_restore_args+0x5/0x6 [ 1257.228964...

...e80 ffff8801046a7400 ffff880105618540 ffff88011198dd78 ffff88011263fef8 Call Trace: [<ffffffff811b469e>] write_ctree_super+0xe/0x10 [<ffffffff811b9778>] btrfs_commit_transaction+0x6a8/0x870 [<ffffffff811b8a8a>] ? join_transaction+0x24a/0x280 [<ffffffff810611f0>] ? wake_up_bit+0x40/0x40 [<ffffffff81195a57>] btrfs_sync_fs+0x47/0x70 [<ffffffff811029be>] __sync_filesystem+0x5e/0x90 [<ffffffff81102a53>] sync_filesystem+0x43/0x60 [<ffffffff810dc226>] generic_shutdown_super+0x36/0xe0 [<ffffffff810dc361>] kill_anon_super+0x11/0x20 [<...

...9.038043] [<ffffffffa0557f01>] ? btrfs_run_delayed_refs+0x1a1/0x2e0 [btrfs] [ 469.038072] [<ffffffffa05c2dd0>] commit_cowonly_roots+0x121/0x1eb [btrfs] [ 469.038099] [<ffffffffa0569aad>] btrfs_commit_transaction+0x59d/0xac0 [btrfs] [ 469.038105] [<ffffffff8107f610>] ? wake_up_bit+0x40/0x40 [ 469.038134] [<ffffffffa05b4d46>] ? __btrfs_scrub_cancel+0x106/0x110 [btrfs] [ 469.038160] [<ffffffffa0564aa6>] btrfs_commit_super+0x86/0x110 [btrfs] [ 469.038185] [<ffffffffa0566358>] close_ctree+0x2c8/0x320 [btrfs] [ 469.038191] [<ffffffff811aa067>] ? ev...

...d13>] ? do_sync_read+0xc9/0x10c Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff802461b1>] ? autoremove_wake_function+0x0/0x2e Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff802460db>] ? bit_waitqueue+0x10/0x97 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff802461a0>] ? wake_up_bit+0x11/0x22 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff802aa5da>] ? d_kill+0x44/0x59 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff8029b504>] ? vfs_read+0xaa/0x152 Apr 20 17:31:52 um-fe-1 [ 9123.585958] [<ffffffff8029b8e5>] ? sys_read+0x45/0x6e Apr 20 17:31:52 um-fe-1 [...

On 06/21/2011 01:15 PM, Jan Stilow wrote: > Hello, > > Nirbheek Chauhan <nirbheek <at> gentoo.org> writes: >> [...] >> >> Every few minutes, (I guess) when applications do fsync (firefox, >> xchat, vim, etc), all applications that use fsync() hang for several >> seconds, and applications that use general IO suffer extreme >> slowdowns.

...+0xf6/0x100 [btrfs] [87703.861541] [<ffffffffa0350a06>] commit_fs_roots+0xc6/0x1c0 [btrfs] [87703.868674] [<ffffffffa0351bcb>] btrfs_commit_transaction+0x5db/0xa50 [btrfs] [87703.876745] [<ffffffff810127a3>] ? __switch_to+0x153/0x440 [87703.882966] [<ffffffff81070a90>] ? wake_up_bit+0x40/0x40 [87703.888997] [<ffffffffa0352040>] ? btrfs_commit_transaction+0xa50/0xa50 [btrfs] [87703.897271] [<ffffffffa035205f>] do_async_commit+0x1f/0x30 [btrfs] [87703.904262] [<ffffffff81068949>] process_one_work+0x129/0x450 [87703.910777] [<ffffffff8106b7eb>] worker_...

Hey Jens, Please in your spare time (if there is such a thing at a conference) pull this branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10 for your v3.10 branch. Sorry for being so late with this. <blurb> It has the ''feature-max-indirect-segments'' implemented in both backend and frontend. The current problem with the backend and

Sorry i don`t copy everything: TEST-MAIL1# echo "ls //orphan_dir:0000"|debugfs.ocfs2 /dev/dm-0|wc debugfs.ocfs2 1.6.4 5239722 26198604 246266859 TEST-MAIL1# echo "ls //orphan_dir:0001"|debugfs.ocfs2 /dev/dm-0|wc debugfs.ocfs2 1.6.4 6074335 30371669 285493670 TEST-MAIL2 ~ # echo "ls //orphan_dir:0000"|debugfs.ocfs2 /dev/dm-0|wc debugfs.ocfs2 1.6.4 5239722 26198604

...lt;ffffffff880a8917>] :sd_mod:sd_revalidate_disk+0xb74/0xc86 [<ffffffff8010c257>] efi_partition+0x0/0x5d4 [<ffffffff8010ad6c>] rescan_partitions+0x132/0x279 [<ffffffff800e56b0>] do_open+0x231/0x30f [<ffffffff800e589c>] __blkdev_get+0x6a/0x7c [<ffffffff8002d0e8>] wake_up_bit+0x11/0x22 [<ffffffff8010abdd>] register_disk+0x133/0x190 [<ffffffff801479df>] add_disk+0x34/0x3d [<ffffffff880a9492>] :sd_mod:sd_probe+0x2f7/0x355 [<ffffffff80056e02>] netlink_broadcast+0x2a9/0x2f1 [<ffffffff801c7d26>] driver_probe_device+0x52/0xaa [<ffffffff801...

i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it''s use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This series removes it in favour of a simpler counter scheme, thus getting rid

Hi all, we got a new test system here and I just also tested btrfs raid6 on that. Write performance is slightly lower than hw-raid (LSI megasas) and md-raid6, but it probably would be much better than any of these two, if it wouldn''t read all the during the writes. Is this a known issue? This is with linux-3.9.2. Thanks, Bernd -- To unsubscribe from this list: send the line

...(pdb->map_anon_vma) + put_anon_vma(pdb->map_anon_vma); + if (pdb->req_anon_vma) + put_anon_vma(pdb->req_anon_vma); + + page_db_free(pdb); + } +} + +static void page_db_release(struct page_db *pdb) +{ + clear_bit(BUSY_BIT, (unsigned long *)&pdb->flags); + /* see comments of wake_up_bit(), set_bit() is atomic */ + smp_mb__after_atomic(); + wake_up_bit(&pdb->flags, BUSY_BIT); +} + +/* Reserve a mapping entry indexed by map_hva in the file database. */ +static struct page_db * +page_db_reserve(struct file_db *fdb, struct mm_struct *req_mm, + unsigned long req_hva, unsigned lo...