On 6/10/21 6:56 PM, Olivier Langlois wrote: > On Thu, 2021-06-10 at 16:51 +0100, Pavel Begunkov wrote: >> Right, but it still stalls other requests and IIRC there are people >> not liking the syscall already taking too long. Consider >> io_req_task_queue(), adds more overhead but will delay execution >> to the syscall exit. >> >> In any case, would be great to have numbers, e.g. to see if >> io_req_task_queue() is good enough, how often your problem >> takes places and how much it gives us. >> > I will get you more more data later but I did run a fast test that > lasted 81 seconds with a single TCP connection. > > The # of times that the sqe got reissued is 57. > > I'll intrumentalize a bit the code to answer the following questions: > > 1. What is the ratio of reissued read sqe/total read sqe > 2. Average exec time of __io_queue_sqe() for a read sqe when data is > already available vs avg exec time when sqe is reissued > 3. average exec time when the sqe is pushed to async when it could have > been reissued. > > With that info, I think that we will be in better position to evaluate > whether or not the patch is good or not. > > Can you think of other numbers that would be useful to know to evaluate > the patch performance? If throughput + latency (avg + several nines) are better (or any other measurable improvement), it's a good enough argument to me, but not sure what test case you're looking at. Single threaded? Does it saturate your CPU? -- Pavel Begunkov
