From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034194AbcIWUbL (ORCPT ); Fri, 23 Sep 2016 16:31:11 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:42606 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752730AbcIWUbJ (ORCPT ); Fri, 23 Sep 2016 16:31:09 -0400 Subject: Re: [PATCH 0/2] Ajust lockdep static allocations To: Peter Zijlstra 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> <20160923201756.GP5008@twins.programming.kicks-ass.net> 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 From: Babu Moger Organization: Oracle Corporation Message-ID: <5b8e679d-c7af-8f60-7724-c05ce2797eb6@oracle.com> Date: Fri, 23 Sep 2016 15:30:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20160923201756.GP5008@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/23/2016 3:17 PM, Peter Zijlstra wrote: > 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. Thanks. Will work on it. > >> 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.