On Thu, Nov 27, 2014 at 04:41:59PM +0100, Jan Kara wrote: > Hum, but this puts lots of stuff under inode_hash_lock, including > writeback list lock. I don't like this too much. I understand that getting > handle for each inode is rather more CPU intensive but it should still be a > clear win over the current situation and avoids entangling locks like this. Hmm, if we dropped the inode_requeue_dirtytime(), then we can avoid taking the writeback list lock. The net result is that we would have some inodes still on the b_dirty_time list that were no longer I_DIRTY_TIME, but since I_DIRTY_TIME wouldn't be set, it's mostly harmless since when we do iterate over the b_dirty_time list, those inodes can be quickly identified and skipped over. (And if the inode ever gets dirtied for real, then it will get moved onto the b_dirty list and that will be that.) The problem with getting a handle on the inode is not just that it is more CPU intensive, but that can't let the iput_final() call happen until after we have finished the transaction handle. We could keep a linked list of inodes attached to the handle, and then only call iput on them once ext4_journal_stop(handle) gets called, but that's a complication I'd like to avoid if at all possible. Being able to opporunistically write the timestamps when we are journalling an inode table block is a pretty big win, so if we end up extending the hold time on inode_hash_lock (only when we come across a I_DIRTY_TIME inode that we can clear) a tiny bit, there will be a lot of workloads where I think it's a worthwhile tradeoff. If we can avoid entangling the writebakc list lock, does that make you happier about this approach? - Ted -- 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
