On 12/22/23 1:35 AM, Xiaobing Li wrote: > On 12/18/23 15:53, Jens Axboe wrote: >> I think I'm convinced that the effectiveness of the chosen SQPOLL >> settings being exposed is useful, I'm just not sure fdinfo is the right >> place to do it. Is it going to be a problem that these are just >> perpetual stats, with no way to reset them? This means there's no way to >> monitor it for a period of time and get effectiveness for something >> specific, it'll always just count from when the ring was created. >> >> We could of course have the act of reading the stat also reset it, but >> maybe that'd be a bit odd? >> >> Alternatively, it could be exported differently, eg as a register opcode >> perhaps. >> >> Open to suggestions... > > I thought carefully about your proposed reset stat, and I think it can be > achieved by outputting "work_time" and "total_time". > eg: > Output at time t1: > SqMask: 0x3 > SqHead: 1168417 > SqTail: 1168418 > SqWorkTime: t1_work > SqTotalTime: t1_total > > Output at time t2: > SqMask: 0x3 > SqHead: 1168417 > SqTail: 1168418 > SqWorkTime: t2_work > SqTotalTime: t2_total > > Then we can manually calculate the utilization rate from t1 to t2: > (t2_work - t1_work) / (t2_total - t1_total) > > Not sure what you think, but if you think it doesn't work, I'll look into > other good ways to add the ability to reset. Yep that would work, just leave the stats calculation to the tool querying it. Which is really how it should be. > In addition, on register opcode - generally it is used for resource like > buffers, handles etc.. I am not sure how that can help here. If you have > something in mind, could you please elaborate in more detail? It's also a bit of a dumping ground for any kind of out-of-band mechanism, so it would work fine for something like this too. But since we already have fdinfo and with your idea of just logging work and total time, then we should probably just stick with that. -- Jens Axboe
