[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <df54eb77-2aad-7801-9ddc-bc085f03d246@oracle.com>
Date: Fri, 23 Sep 2016 09:04:42 -0500
From: Babu Moger <babu.moger@...cle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, akpm@...ux-foundation.org, keescook@...omium.org,
dan.j.williams@...el.com, aryabinin@...tuozzo.com, tj@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Ajust lockdep static allocations
On 9/23/2016 2:12 AM, Peter Zijlstra wrote:
> On Thu, Sep 22, 2016 at 11:43:34AM -0700, Babu Moger wrote:
>> These patches adjust the static allocations for lockdep
>> data structures used for debugging locking correctness. The current
>> code reserves about 4MB extra space for these data structures. Most
>> of the configurations do not need these many data structures. While
>> testing, I have not seen it go beyond 20% of already reserved entries.
>>
>> $grep "lock-classes" /proc/lockdep_stats
>> lock-classes: 1560 [max: 8191]
>>
>> Reserving even more space seems unreasonable. So, keeping the default
>> entries small as before the Commit 1413c0389333 ("lockdep: Increase static
>> allocations"). Added new CONFIG_PROVE_LOCKING_PLUS in case someone
>> needs more entries to debug their large configuration.
> Why make this more complicated? There's absolutely no upside to this
> change as far as I can see.
Peter, What do you mean? Revert the commit 1413c038933? Right now,
I cannot boot my setup after enabling lockdep. How do you think we can
handle this?
Powered by blists - more mailing lists