Re: [PATCH 0/2] Ajust lockdep static allocations

[Rob Gardner]

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@xxxxxxxxxxxxxxx/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