On Thu, Jun 27, 2013 at 07:59:50PM -1000, Linus Torvalds wrote: > Also, looking some more now at that wait_sb_inodes logic, I have to > say that if the problem is primarily the inode->i_lock, then that's > just crazy.
Looks more like contention on inode_sb_list_lock, actually... > And no, I don't think really need the i_lock for checking > "mapping->nrpages == 0" or the magical "inode is being freed" bits > either. Or at least we could easily do some of this optimistically for > the common cases. > I'm attaching a pretty trivial patch, which may obviously be trivially > totally flawed. I have not tested this in any way, but half the new > lines are comments about why it's doing what it is doing. And I > really think that it should make the "actually take the inode lock" be > something quite rare. > > And quite frankly, I'd much rather get *rid* of crazy i_lock accesses, > than try to be clever and use a whole different list at this point. > Not that I disagree that it wouldn't be much nicer to use a separate > list in the long run, but for a short-term solution I'd much rather > keep the old logic and just tweak it to be much more usable.. > > Hmm? Al? Jan? Comments? Patch seems to be sane, but I'm not sure how much will it buy in that case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
