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
