From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760266AbcIWUSH (ORCPT ); Fri, 23 Sep 2016 16:18:07 -0400 Received: from merlin.infradead.org ([205.233.59.134]:51020 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759978AbcIWUSG (ORCPT ); Fri, 23 Sep 2016 16:18:06 -0400 Date: Fri, 23 Sep 2016 22:17:56 +0200 From: Peter Zijlstra To: Babu Moger Cc: mingo@redhat.com, akpm@linux-foundation.org, keescook@chromium.org, dan.j.williams@intel.com, aryabinin@virtuozzo.com, tj@kernel.org, linux-kernel@vger.kernel.org, Rob Gardner , davem@davemloft.net Subject: Re: [PATCH 0/2] Ajust lockdep static allocations Message-ID: <20160923201756.GP5008@twins.programming.kicks-ass.net> References: <1474569816-170269-1-git-send-email-babu.moger@oracle.com> <20160923071246.GJ2794@worktop> <20160923143413.GM5008@twins.programming.kicks-ass.net> <71daf047-059d-3478-9e08-989d44211a9c@oracle.com> <20160923150439.GD5012@twins.programming.kicks-ass.net> <842fdad9-638e-f98c-5e3d-c3e698943e30@oracle.com> <20160923154041.GO5008@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 23, 2016 at 02:57:39PM -0500, Babu Moger wrote: > We checked again. Yes, It goes in .bss section. But in sparc we have > to fit .text, .data, .bss in 7 permanent TLBs(that is totally 28MB). > It was fine so far. But the commit 1413c0389333 ("lockdep: Increase > static allocations") added extra 4MB which makes it go beyond 28MB. > That is causing system boot up problems in sparc. *sigh*, why didn't you start with that :/ > Yes. We know it. This is a limitation. Changing this limit in our > hardware is a much bigger change which we cannot address right away. > So, we are trying to come up with a solution which can work for all. I > will re-post the patches with CONFIG_BASE_SMALL option if there is no > objections. OK, so double check BASE_SMALL doesn't imply other things you cannot live with, Sparc64 isn't a dinky system. If BASE_SMALL works for you then good, otherwise do a PROVE_LOCKING_SMALL symbol that is not user selectable and have SPARC select that. Use the invisible Help for that symbol to explain all this again. > CCing David Miller and Rob Gardner. They might be able to explain > more if you have any more questions. Nah, I think I remember enough of how the Sparc MMU works to see reason.