On Tue, May 10, 2022 at 02:37:40PM +0900, Byungchul Park wrote:
Ted wrote:
On Tue, May 10, 2022 at 09:32:13AM +0900, Byungchul Park wrote:
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.
Look. Let's talk in general terms. There's no way to get rid of the false positives all the way. It's a decision issue for *balancing* between considering potential cases and only real ones. Definitely, potential is not real. The more potential things we consider, the higher the chances are, that false positives appear.
But yes. The advantage we'd take by detecting potential ones should be higher than the risk of being bothered by false ones. Do you think a tool is useless if it produces a few false positives? Of course, it'd be a problem if it's too many, but otherwise, I think it'd be a great tool if the advantage > the risk.
Don't get me wrong here. It doesn't mean DEPT is perfect for now. The performance should be improved and false alarms that appear should be removed, of course. I'm talking about the direction.
For now, there's no tool to track wait/event itself in Linux kernel - a subset of the functionality exists tho. DEPT is the 1st try for that purpose and can be a useful tool by the right direction.
I know what you are concerning about. I bet it's false positives that are going to bother you once merged. I'll insist that DEPT shouldn't be used as a mandatory testing tool until considered stable enough. But what about ones who would take the advantage use DEPT. Why don't you think of folks who will take the advantage from the hints about dependency of synchronization esp. when their subsystem requires very complicated synchronization? Should a tool be useful only in a final testing stage? What about the usefulness during development stage?
It's worth noting DEPT works with any wait/event so any lockups e.g. even by HW-SW interface, retry logic or the like can be detected by DEPT once all waits and events are tagged properly. I believe the advantage by that is much higher than the bad side facing false alarms. It's just my opinion. I'm goning to respect the majority opinion.
s/take advantage/have the benefit/g
Byungchul