On Sat, Dec 29, 2007 at 11:16:15PM -0700, Matthew Wilcox wrote:
> It seems to work well enough, but I haven't run any serious stress
> tests on it. This implementation uses one spinlock to protect both lock
> lists and all the i_flock chains. It doesn't seem worth splitting up
> the locking any further.
If people are really having any kind of scalability problems with this
still it should be quite trivial to make the file_lock_list and
blocked_list aswel as the new file_lock_lock per-superblock as file
and thus locks never move between superblocks. In fact I'd probably
do this even without scalability concerns just to make our fs data
structures nice per-superblock.
> I had to move one memory allocation out from under the file_lock_lock.
> I hope I got that logic right. I'm rather tempted to split out the
> find_conflict algorithm from that function into something that can be
> called separately for the FL_ACCESS case.
Yes, splitting that out makes a lot of sense. Should be a separate
patch, though.
> +static inline void lock_flocks(void)
> +{
> + spin_lock(&file_lock_lock);
> +}
> +
> +static inline void unlock_flocks(void)
> +{
> + spin_unlock(&file_lock_lock);
> +}
I'd rather not introduce this wrappers, they only obsfucated what's
really going on.
> + if (found) {
> + unlock_flocks();
> cond_resched();
> + lock_flocks();
> + }
There's a cond_resched_lock that only drops the lock in case we really
need to block.
-
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
