On Tue, 2006-10-24 at 15:34 -0400, Chris Mason wrote: > Hello, > > Here is a new cut of my O_DIRECT locking rework. It has a much lower > cpu cost than the last set, and simple benchmarks no longer show a > regression here in system time. But, the complexity for inserting > placeholder pages has gone up. > > I've also changed the way I test for a place holder page (from > mm/filemap.c): > > static struct address_space placeholder_address_space; > #define PagePlaceHolder(page) ((page)->mapping == &placeholder_address_space) > > This is more stable than the last one but I'm just starting to run race > and load testing on it. > > -chris Gave it a spin with simple fsx tests and ran into .. ===================================== [ BUG: bad unlock balance detected! ] ------------------------------------- fsx-linux/2409 is trying to release lock (&inode->i_mutex) at: [<ffffffff804a09e9>] mutex_unlock+0x9/0xb but there are no more locks to release! other info that might help us debug this: no locks held by fsx-linux/2409. stack backtrace: Call Trace: [<ffffffff8020b0d7>] dump_trace+0xaa/0x3ed [<ffffffff8020b456>] show_trace+0x3c/0x52 [<ffffffff8020b481>] dump_stack+0x15/0x17 [<ffffffff8024b269>] print_unlock_inbalance_bug+0x108/0x118 [<ffffffff8024cf32>] lock_release+0x92/0x13d [<ffffffff804a0977>] __mutex_unlock_slowpath+0xbf/0x128 [<ffffffff804a09e9>] mutex_unlock+0x9/0xb [<ffffffff802b56b8>] __blockdev_direct_IO+0x961/0xb37 [<ffffffff80301813>] ext3_direct_IO+0xf4/0x192 [<ffffffff8026794a>] generic_file_direct_IO+0xa2/0xeb [<ffffffff8026951e>] generic_file_aio_read+0xc7/0x19d [<ffffffff8028f589>] do_sync_read+0xe2/0x126 [<ffffffff8028fe39>] vfs_read+0xcc/0x172 [<ffffffff80290240>] sys_read+0x47/0x6f [<ffffffff80209cee>] system_call+0x7e/0x83 DWARF2 unwinder stuck at system_call+0x7e/0x83 Leftover inexact backtrace: - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
