lkml.org 
[lkml]   [2023]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2023-03-27 00:20    [W:0.098 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site