On Thu, Dec 12, 2024 at 6:30 PM Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > > Yes, based on the comments received so far I agree that generic timeout is the > > prefered approach. Looks like we are amongst the few that run production > > systems with hung task panic set. So yeah, I will match fuse max request > > timeout with hung task timeout to get the equivalent behavior. > > Sounds great. Just FYI, the timeouts in fuse won't be 100% precise - > they'll have an upper margin of error associated with it (this is > included in the documentation for the sysctl, since it's very > non-obvious). For example, if the max request timeout is set to 600 > seconds, it may fire off a little after 600 seconds. So it'd be best > if you set the fuse max request timeout to be below the hung task > timeout to be sure. IIRC, Sergey is doing the same thing [1]. > Understood yes. > > [1] https://lore.kernel.org/linux-fsdevel/20241128115455.GG10431@xxxxxxxxxx/ > > > > > On a slightly different matter, I realized that in some scenarios > > there is no benefit > > in stopping the timer when reaching the last request because another > > request can come > > right after and then we have to start the timer once again which keeps bouncing > > between cancel_delayed_work_sync() and queue_delayed_work(). > > > > So I think it's best to stick with your approach of starting the timer > > when the connection > > is initially established. I can re-work this patch if needed? > > Thanks for testing out the timeout functionality. I'm planning to > submit v10 of the generic timeout patch to use workqueues early next > week. The time granularity will also be changed to work in seconds > instead of minutes, as noted for Sergey's and your use case. I'll make > sure you get cc'ed on that patchset. Thank you very much. I'll take a look thanks Etienne
