On Fri, Mar 04, 2022 at 10:26:23PM -0500, Theodore Ts'o wrote: > 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. :-) Almost all you've been blaming at Dept are totally non-sense. Based on what you're saying, I'm conviced that you don't understand how Dept works even 1%. You don't even try to understand it before blame. You don't have to understand and support it. But I can't response to you if you keep saying silly things that way. > 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 Dept is going to be improved so that what you are concerning about won't be reported. > by DEPT --- because Lockdep give us actionable reports, and if DEPT Right. Dept should give actionable reports, too. > can't tell the difference between a valid programming pattern and a > bug, then it's worse than useless. Needless to say.
