On Fri, Mar 04, 2022 at 09:42:37AM +0900, Byungchul Park wrote: > > All contexts waiting for any of the events in the circular dependency > chain will be definitely stuck if there is a circular dependency as I > explained. So we need another wakeup source to break the circle. In > ext4 code, you might have the wakeup source for breaking the circle. > > What I agreed with is: > > The case that 1) the circular dependency is unevitable 2) there are > another wakeup source for breadking the circle and 3) the duration > in sleep is short enough, should be acceptable. > > Sounds good? These dependencies are part of every single ext4 metadata update, and if there were any unnecessary sleeps, this would be a major performance gap, and this is a very well studied part of ext4. There are some places where we sleep, sure. In some case start_this_handle() needs to wait for a commit to complete, and the commit thread might need to sleep for I/O to complete. But the moment the thing that we're waiting for is complete, we wake up all of the processes on the wait queue. But in the case where we wait for I/O complete, that wakeupis coming from the device driver, when it receives the the I/O completion interrupt from the hard drive. Is that considered an "external source"? Maybe DEPT doesn't recognize that this is certain to happen just as day follows the night? (Well, maybe the I/O completion interrupt might not happen if the disk drive bursts into flames --- but then, you've got bigger problems. :-) In any case, if DEPT is going to report these "circular dependencies as bugs that MUST be fixed", it's going to be pure noise and I will ignore all DEPT reports, and will push back on having Lockdep replaced by DEPT --- because Lockdep give us actionable reports, and if DEPT can't tell the difference between a valid programming pattern and a bug, then it's worse than useless. Sounds good? - Ted
