> On Feb 19, 2019, at 10:13 AM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-02-19 at 09:54 -0500, Chuck Lever wrote: >> Hi Trond- >> >>> On Feb 19, 2019, at 9:06 AM, Trond Myklebust <trondmy@xxxxxxxxx> >>> wrote: >>> >>> Because we clear XPRT_SOCK_DATA_READY before reading, we can end up >>> with a situation where new data arrives, causing xs_data_ready() to >>> queue up a second receive worker job for the same socket, which >>> then >>> immediately gets stuck waiting on the transport receive mutex. >>> The fix is to only clear XPRT_SOCK_DATA_READY once we're done >>> reading, >>> and then to use poll() to check if we might need to queue up a new >>> job in order to deal with any new data. >> >> Does this fix an application-visible hang, or is it merely a >> performance >> optimization? > > I'm not aware of any hang associated with this behaviour. The patch is > rather intended as an optimisation to avoid having these threads block > uselessly on a mutex. That was my guess, thanks, just wanted to make certain. -- Chuck Lever