On Tue, May 10, 2022 at 09:32:13AM +0900, Byungchul Park wrote: > Yes, right. DEPT has never been optimized. It rather turns on > CONFIG_LOCKDEP and even CONFIG_PROVE_LOCKING when CONFIG_DEPT gets on > because of porting issue. I have no choice but to rely on those to > develop DEPT out of tree. Of course, that's what I don't like. Sure, but blaming the overhead on unnecessary CONFIG_PROVE_LOCKING overhead can explain only a tiny fraction of the slowdown. Consider: if time to first test (time to boot the kernel, setup the test environment, figure out which tests to run, etc.) is 12 seconds w/o LOCKDEP, 49 seconds with LOCKDEP/PROVE_LOCKING and 602 seconds with DEPT, you can really only blame 37 seconds out of the 602 seconds of DEPT on unnecessary PROVE_LOCKING overhead. So let's assume we can get rid of all of the PROVE_LOCKING overhead. We're still talking about 12 seconds for time-to-first test without any lock debugging, versus ** 565 ** seconds for time-to-first test with DEPT. That's a factor of 47x for DEPT sans LOCKDEP overhead, compared to a 4x overhead for PROVE_LOCKING. > Plus, for now, I'm focusing on removing false positives. Once it's > considered settled down, I will work on performance optimizaition. But > it should still keep relying on Lockdep CONFIGs and adding additional > overhead on it until DEPT can be developed in the tree. Well, please take a look at the false positive which I reported. I suspect that in order to fix that particular false positive, we'll either need to have a way to disable DEPT on waiting on all page/folio dirty bits, or it will need to treat pages from different inodes and/or address spaces as being entirely separate classes, instead of collapsing all inode dirty bits, and all of various inode's mutexes (such as ext4's i_data_sem) as being part of a single object class. > DEPT is tracking way more objects than Lockdep so it's inevitable to be > slower, but let me try to make it have the similar performance to > Lockdep. In order to eliminate some of these false positives, I suspect it's going to increase the number of object classes that DEPT will need to track even *more*. At which point, the cost/benefit of DEPT may get called into question, especially if all of the false positives can't be suppressed. - Ted
