On Mon, Feb 13, 2023 at 11:18:50AM -0500, Alan Stern wrote: > On Mon, Feb 13, 2023 at 10:49:50AM +0100, Peter Zijlstra wrote: > > My main worry when adding a ton of classes like this is the > > combinatorics (dynamic classes make this more trivial, but it's entirely > > possible with just static classes too). > > > > As an example, we used to have a static class per cpu runqueue, now, > > given migration takes two runqueue locks (per locking rules in cpu > > order -- source and dest runqueue etc..) we got O(n^2) combinations of > > class orderings, which lead to a giant graph, which led to both > > performance and memory usage issues. > > Having a new class for each device would add a lot of classes. Just how > badly this would affect lockdep's performance is hard to predict. > Testing seems like the best way to find out. We support systems with 50000+ devices today, so one class per device might be messy. But back to the original issue here, why any of this? What's wrong with what we have now? I haven't seen real locking issues reported yet (only odd syzbot reports that didn't make any sense.) Is this effort even worth it? thanks, greg k-h
