On Sun, 2017-12-03 at 15:19 -0500, Chuck Lever wrote:
> > On Dec 3, 2017, at 3:12 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxx
> > m> wrote:
> >
> > On Sun, 2017-12-03 at 13:54 -0500, Chuck Lever wrote:
> > > > On Dec 3, 2017, at 1:50 PM, Trond Myklebust <trond.myklebust@pr
> > > > imar
> > > > ydata.com> wrote:
> > > >
> > > > We must ensure that the call to rpc_sleep_on() in
> > > > xprt_transmit()
> > > > cannot
> > > > race with the call to xprt_complete_rqst().
> > >
> > > :-( this will kill scalability, we might as well just go back
> > > to the old locking scheme.
> >
> > It shouldn't make a huge difference, but I agree that we do want to
> > get
> > rid of that transport lock.
> >
> > How about the following, then?
>
> This looks better, I'll give it a try!
>
> But touching the recv_lock in the transmit path is what I'd like
> to avoid completely, if possible. I'm not clear on why the pending
> waitqueue is unprotected. Doesn't it have a lock of its own?
The recv_lock ensures that the check of req->rq_reply_bytes_recvd is
atomic with the call to rpc_sleep_on().
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
