> On Jul 3, 2023, at 10:30 PM, NeilBrown <neilb@xxxxxxx> wrote: > > On Tue, 04 Jul 2023, Chuck Lever wrote: >> On Tue, Jul 04, 2023 at 10:45:20AM +1000, NeilBrown wrote: >>> On Tue, 04 Jul 2023, Chuck Lever wrote: >>>> From: Chuck Lever <chuck.lever@xxxxxxxxxx> >>>> >>>> To get a sense of the average number of transport enqueue operations >>>> needed to process an incoming RPC message, re-use the "packets" pool >>>> stat. Track the number of complete RPC messages processed by each >>>> thread pool. >>> >>> If I understand this correctly, then I would say it differently. >>> >>> I think there are either zero or one transport enqueue operations for >>> each incoming RPC message. Is that correct? So the average would be in >>> (0,1]. >>> Wouldn't it be more natural to talk about the average number of incoming >>> RPC messages processed per enqueue operation? This would be typically >>> be around 1 on a lightly loaded server and would climb up as things get >>> busy. >>> >>> Was there a reason you wrote it the way around that you did? >> >> Yes: more than one enqueue is done per incoming RPC. For example, >> svc_data_ready() enqueues, and so does svc_xprt_receive(). >> >> If the RPC requires more than one call to ->recvfrom() to complete >> the receive operation, each one of those calls does an enqueue. >> > > Ahhhh - that makes sense. Thanks. > So its really that a number of transport enqueue operations are needed > to *receive* the message. Once it is received, it is then processed > with no more enqueuing. > > I was partly thrown by the fact that the series is mostly about the > queue of threads, but this is about the queue of transports. > I guess the more times a transport if queued, the more times a thread > needs to be woken? Yes: this new metric is an indirect measure of the workload on the new thread wake-up mechanism. -- Chuck Lever
