On 11/12/2018 02:22 PM, Josh Poimboeuf wrote: > On Mon, Nov 12, 2018 at 07:30:50AM +0100, Ingo Molnar wrote: >> * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: >> >>> On Mon, Nov 12, 2018 at 06:10:33AM +0100, Ingo Molnar wrote: >>>> * Waiman Long <longman@xxxxxxxxxx> wrote: >>>> >>>>> On 11/10/2018 09:10 AM, Peter Zijlstra wrote: >>>>>> On Fri, Nov 09, 2018 at 09:04:12AM +0100, Ingo Molnar wrote: >>>>>>> BTW., if you are interested in more radical approaches to optimize >>>>>>> lockdep, we could also add a static checker via objtool driven call graph >>>>>>> analysis, and mark those locks terminal that we can prove are terminal. >>>>>>> >>>>>>> This would require the unified call graph of the kernel image and of all >>>>>>> modules to be examined in a final pass, but that's within the principal >>>>>>> scope of objtool. (This 'final pass' could also be done during bootup, at >>>>>>> least in initial versions.) >>>>>> Something like this is needed for objtool LTO support as well. I just >>>>>> dread the build time 'regressions' this will introduce :/ >>>>>> >>>>>> The final link pass is already by far the most expensive part (as >>>>>> measured in wall-time) of building a kernel, adding more work there >>>>>> would really suck :/ >>>>> I think the idea is to make objtool have the capability to do that. It >>>>> doesn't mean we need to turn it on by default in every build. >>>> Yeah. >>>> >>>> Also note that much of the objtool legwork would be on a per file basis >>>> which is reasonably parallelized already. On x86 it's also already done >>>> for every ORC build i.e. every distro build and the incremental overhead >>>> from also extracting locking dependencies should be reasonably small. >>>> >>>> The final search of the global graph would be serialized but still >>>> reasonably fast as these are all 'class' level dependencies which are >>>> much less numerous than runtime dependencies. >>>> >>>> I.e. I think we are talking about tens of thousands of dependencies, not >>>> tens of millions. >>>> >>>> At least in theory. ;-) >>> Generating a unified call graph sounds very expensive (and very far >>> beyond what objtool can do today). >> Well, objtool already goes through the instruction stream and recognizes >> function calls - so it can in effect generate a stream of "function x >> called by function y" data, correct? > Yeah, though it would be quite simple to get the same data with a simple > awk script at link time. > >>> Also, what about function pointers? >> So maybe it's possible to enumerate all potential values for function >> pointers with a reasonably simple compiler plugin and work from there? > I think this would be somewhere between very difficult and impossible to > do properly. I can't even imagine how this would be implemented in a > compiler plugin. But I'd love to be proven wrong on that. I would say we have to assume for the worst when a function pointer is being called while holding a lock unless we are able to find out all its possible targets. Cheers, Longman
