Davide Libenzi <davidel@xxxxxxxxxxxxxxx> writes: > On Tue, 2 Jun 2009, Eric W. Biederman wrote: > >> I am not clear what problem you have. >> >> Is it the sprinkling the code that takes and removes the lock? Just >> the VFS needs to be involved with that. It is a slightly larger >> surface area than doing the work inside the file operations as we >> sometimes call the same method from 3-4 different places but it is >> definitely a bounded problem. >> >> Is it putting in the handful lines per subsystem to actually use this >> functionality? At that level something generic that is maintained >> outside of the subsystem is better than the mess we have with 4-5 >> different implementations in the subsystems that need it, each having >> a different assortment of bugs. > > Come on, only in the open fast path, there are at least two spin > lock/unlock and two atomic ops. Without even starting to count all the > extra branches and software added. > Is this stuff *really* needed, or we can faitly happily live w/out? ???? What code are you talking about? To the open path a few memory writes and a smp_wmb. No atomics and no spin lock/unlocks. Are you complaining because I retain the file_list? Eric -- 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
