On Sun, Feb 18, 2018 at 07:02:37PM +0500, Mikhail Gavrilov wrote: > On 16 February 2018 at 02:48, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Fri, Feb 16, 2018 at 12:02:28AM +0500, Mikhail Gavrilov wrote: > >> On 15 February 2018 at 10:44, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > >> > I've already explained that we can't annotate these memory > >> > allocations to turn off the false positives because that will also > >> > turning off all detection of real deadlock conditions. Lockdep has > >> > many, many limitations, and this happens to be one of them. > >> > > >> > FWIW, is there any specific reason you running lockdep on your > >> > desktop system? > >> > >> Because I wanna make open source better (help fixing all freezing) > > > > lockdep isn't a user tool - most developers don't even understand > > what it tries to tell them. Worse, it is likely contributing to your > > problems as it has a significant runtime CPU and memory overhead.... > > I don't know how else collect debug info about freezes which occurring > accidentally. Is there a better idea? Lockdep tells us about locking problems, not arbitrary operational latencies. Go look at the bcc collection of tools for tracking down where latencies occur in the system. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
