On Mon, 28 May 2012 22:03:44 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Mon, May 28, 2012 at 7:30 PM, Richard Sharpe > <realrichardsharpe@xxxxxxxxx> wrote: > > Hi folks, > > > > I am reading the code because I am interested in adding SMB2.2/3.0 > > support around multi-connect. > > > > I noticed the following code, which confuses me. > > > > /* put it on the pending_mid_q */ > > spin_lock(&GlobalMid_Lock); > > list_add_tail(&mid->qhead, &server->pending_mid_q); > > spin_unlock(&GlobalMid_Lock); > > > > rc = cifs_sign_smb2(iov, nvec, server, &mid->sequence_number); > > if (rc) > > cifs_delete_mid(mid); > > *ret_mid = mid; > > return rc; > > > > Since MIDs are allocated on a per-server basis and the list that the > > new struct mid_q_entry is placed on is in the struct TCP_Server_Info > > why are we using GlobalMid_Lock. It seems that we could move that > > spinlock into struct TCP_Server_Info. > > > > What am I missing here? > > Yes - probably could be moved to the srv_mutex in struct > TCP_Server_Info although it is unlikely to make a measurable > difference. > Breaking up that global lock is long overdue, but let's not overload the srv_mutex with that -- mutexes have much higher overhead than a spinlock. A new per-TCP_Server_Info spinlock would be preferable. -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
