Messages in this thread | | | Date | Mon, 13 Feb 2023 18:51:57 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH RFC] drivers/core: Replace lockdep_set_novalidate_class() with unique class keys |
| |
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
| |