On Tue, May 29, 2012 at 8:03 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > 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. agreed -- Thanks, Steve -- 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
