> On Jul 18, 2023, at 8:39 PM, NeilBrown <neilb@xxxxxxx> wrote: > > 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". In the current code, the only way to get to "return -EAGAIN;" is if the thread calls schedule_timeout() (ie, it actually sleeps), then the svc_rqst was specifically selected and awoken, and the schedule_timeout() did not time out. I don't see a problem. > 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. So this one can be dropped for now since it's currently of value only for working on the scheduler changes. If the thread scheduler were to change such that a work item was actually assigned to a thread before it is awoken (a la, a work queue model) then this counter would be truly meaningless. I think we can wait for a bit. -- Chuck Lever
