On Sun, Dec 30, 2007 at 01:05:10PM +0000, Christoph Hellwig wrote:
> 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.
Hrm. file_lock_list is used for /proc/locks, so that's OK to convert,
we just need to iterate over each super block in the system, acquire the
sb_file_lock_lock, then iterate over each sb_file_lock_list.
The blocked_list is a bit more complex since we need to check every lock
on the blocked list, and would need to acquire all the sb_file_lock_locks
to check this list consistently. I don't see a nice way to do this --
particularly when you consider that we need to run this check every time
someone takes out a POSIX lock that blocks on another lock.
> > 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.
Indeed. What you see here is just me hacking until stuff works.
> > +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.
Fair enough. file_lock_lock is a crappy name though, and I was
embarrassed to use it everywhere.
> > + 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.
Ooh, thanks, I didn't know about that.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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
