On Sun, 2007-12-30 at 16:17 +0100, Andi Kleen wrote: > Matthew Wilcox <matthew@xxxxxx> writes: > > > > 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. > > Have you considered using a timeout approach? e.g. just start a timer > when aquiring the lock and when you can't get it in some short (user configurable) > time and only do then the expensive deadlock check. Timers are quite optimized > and have per cpu state so they should be cheap enough. > > AFAIK that's a standard technique used in databases. Advantage is that it > keeps all that out of the fast path. > > Disadvantage is that it takes at least timeout time to detect a deadlock, but > they should be infrequent anyways I guess so it's hopefully not a problem > (and if it was the user could reset the timeout to 0) I like this idea. The only problem I can see from an NFS perspective is with NFSv2/v3 locking: unfortunately the protocol provides no way for the server to notify that a lock may not be granted after the client has been told to block. You would therefore have to bend the protocol rules by simply delaying replying to the client until the deadlock timeout occurred instead of telling it to block. I'm not sure that all clients would be able to cope... Cheers Trond - 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
