lkml.org 
[lkml]   [2016]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] Ajust lockdep static allocations
From
Date
On 09/23/2016 01:57 PM, Babu Moger wrote:
>
> On 9/23/2016 10:40 AM, Peter Zijlstra wrote:
>> On Fri, Sep 23, 2016 at 10:15:46AM -0500, Babu Moger wrote:
>>
>>>>> Correct, We can't boot with lockdep. Sorry I did not make
>>>>> that clear.
>>>>> We have a limit on static size of the kernel.
>>>> This stuff should be in .bss not .data. It should not affect the
>>>> static
>>>> size at all. Or am I misunderstanding things?
>>> Here it is.
>>> $ ./scripts/bloat-o-meter vmlinux.lockdep.small vmlinux.lockdep.big
>> What does bloat-o-meter have to do with things? The static image size is
>> not dependent on .bss, right?
>
> Peter,
> 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.
> 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.
>
> CCing David Miller and Rob Gardner. They might be able to explain
> more if you
> have any more questions. Here is the discussion thread if you guys
> want to look at history.
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1237642.html
>
>
>

Yes, perhaps I can help clarify the problem Babu is seeing. It is true
that stuff in bss doesn't increase the static size of the file that
contains the kernel. But it does increase the kernel's memory footprint.
And as the system is booting, all the kernel's code, data, and bss, must
have locked translations in the TLB so that we don't get TLB misses on
kernel code and data. Current sparc chips have 8 TLB entries available
that may be locked down, and with a 4mb page size, this gives a maximum
of 32mb of memory that can be covered. One of these is used for kexec (I
think), so that leaves 28mb. It sounds to me like Babu is saying that
the change in question has increased the size of bss data so this limit
is exceeded, thus causing boot problems, and he proposes to somewhat
reduce the added space to alleviate this problem.

And also as Babu says, changing to a larger page size is very tricky.
Not only do different sparc cpus support a different set of h/w page
sizes, the effects of changing this are quite far reaching and would
affect a lot of code.

Rob Gardner


\
 
 \ /
  Last update: 2016-09-23 22:10    [W:4.052 / U:0.628 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site