> Putting an IOQ in the SVCXPRT would require constant lock thrashing,

> because each svc_req is on a separate asynchronous thread. You can

> have many simultaneous svc_req going.

Today, we have one IOQ that is being used. It is just a list of responses to be sent over all xprts. How would making a list per xprt be worse than what it is today? Is it because of CPU cache-lines or something else?

Regards, Malahal

On Sat, Sep 15, 2018 at 11:15 PM, William Allen Simpson <william.allen.simpson@gmail.com> wrote:

On 9/14/18 11:00 PM, Matt Benjamin wrote:

That's how it was when the ioq was introduced. I think Daniel has a
fix in mind, but by all means, send this too.

I have gone back and looked, and there is nothing in the historical
code that supports this statement. There was no IOQ in the SVCXPRT.

Nor would that be a good idea. The IOQ structure is designed to
handle a stream made up of segments. It is utilized per nfs_req,
not by the SVCXPRT.

On Fri, Sep 14, 2018 at 10:42 PM, Malahal Naineni <malahal@gmail.com> wrote:

I would put the IOQ in xprt itself as you did. Please post the patch and let
us review it.

Putting an IOQ in the SVCXPRT would require constant lock thrashing,
because each svc_req is on a separate asynchronous thread. You can
have many simultaneous svc_req going....

I've spent an awful lot of time getting rid of the terrible locking
problems we had in the past. Please don't do that again!

(Malahal had helped identify those hot locks in the past.)