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


Reply via email to