Messages in this thread | | | Date | Mon, 23 May 2022 10:10:45 +0900 | From | Byungchul Park <> | Subject | Re: [REPORT] syscall reboot + umh + firmware fallback |
| |
On Thu, May 12, 2022 at 09:56:46AM -0400, Theodore Ts'o wrote: > On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote: > > I have a question about this one. Yes, it would never been stuck thanks > > to timeout. However, IIUC, timeouts are not supposed to expire in normal > > cases. So I thought a timeout expiration means not a normal case so need > > to inform it in terms of dependency so as to prevent further expiraton. > > That's why I have been trying to track even timeout'ed APIs. > > As I beleive I've already pointed out to you previously in ext4 and > ocfs2, the jbd2 timeout every five seconds happens **all** the time > while the file system is mounted. Commits more frequently than five > seconds is the exception case, at least for desktops/laptop workloads.
Thanks, Ted. It's easy to stop tracking APIs with timeout. I've been just afraid that the cases that we want to suppress anyway will be skipped.
However, I should stop it if it produces too many false alarms.
> We *don't* get to the timeout only when a userspace process calls > fsync(2), or if the journal was incorrectly sized by the system > administrator so that it's too small, and the workload has so many > file system mutations that we have to prematurely close the > transaction ahead of the 5 second timeout.
Yeah... It's how journaling works. Thanks.
> > Do you think DEPT shouldn't track timeout APIs? If I was wrong, I > > shouldn't track the timeout APIs any more. > > DEPT tracking timeouts will cause false positives in at least some > cases. At the very least, there needs to be an easy way to suppress > these false positives on a per wait/mutex/spinlock basis.
The easy way is to stop tracking those that are along with timeout until DEPT starts to consider waits/events by timeout functionality itself.
Thanks.
Byungchul > > - Ted
| |