On Tue, 11 Jul 2023, Chuck Lever III wrote: > > > On Jul 10, 2023, at 6:29 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > On Tue, 11 Jul 2023, Chuck Lever wrote: > >> From: Chuck Lever <chuck.lever@xxxxxxxxxx> > >> > >> Measure a source of thread scheduling inefficiency -- count threads > >> that were awoken but found that the transport queue had already been > >> emptied. > >> > >> An empty transport queue is possible when threads that run between > >> the wake_up_process() call and the woken thread returning from the > >> scheduler have pulled all remaining work off the transport queue > >> using the first svc_xprt_dequeue() in svc_get_next_xprt(). > > > > I'm in two minds about this. The data being gathered here is > > potentially useful > > It's actually pretty shocking: I've measured more than > 15% of thread wake-ups find no work to do. I'm now wondering if that is a reliable statistic. This counter as implemented doesn't count "pool threads that were awoken but found no work to do". Rather, it counts "pool threads that found no work to do, either after having been awoken, or having just completed some other request". And it doesn't even really count that is it doesn't notice that lockd "retry blocked" work (or the NFSv4.1 callback work, but we don't count that at all I think). Maybe we should only update the count if we had actually been woken up recently. NeilBrown
