Messages in this thread | | | Date | Thu, 26 Apr 2007 11:27:30 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: 2.6.21-rc7-mm2 -- PPC link failure |
| |
On Thu, 26 Apr 2007, Andy Whitcroft wrote:
> > Ok, this is a SLUB related link failure. Am investigating if PPC simply > > needs larger allocs and needs CONFIG_LARGE_ALLOCS, of if this is an > > inlining issue. > > Ok this is confirmed as an inlining issue. With the compiler below on > ppc64 we get the above link failure: > > gcc version 3.3.3 (SuSE Linux) > > What seems to happen is that although the optimiser is capable of > collapsing the kmalloc_index() call it then fails to collapse > kmalloc_slab(). This leads to the never used reference to > __kmalloc_size_too_large() and the link failure. From my testing this > seems to occur at sizes >= 32k. At 16k all of the code collapses
Interesting. Why would that boundary be of relevance to the compiler? Some offset heuristics?
> correctly, at 32k it does not. I am not entirely sure what to think at > this point, it is cirtainly not at all clear why the 32k version fails > and the 16k succeeds they are almost identical.
Likely a backend optimization issue.
> Either way it seems to me that assuming the optimiser will remove the > code is perhaps over optimistic. Perhaps it would make more sense to > put a BUG() in here. Though that points out the anomaly that the > kmalloc() for constants has different semantics to that for variable values?
Yes but that has always been the case. We want to reduce kmalloc for constants at compile time to use the appropriate kmalloc cache. If kmalloc does not use a constant then we will do run time determination of the kmalloc cache.
The code in SLAB is easier to fold since it does not use a subroutine call.
We could simply #ifdef out the __kmalloc_sizes_too_large for ppc and let it fall back to __kmalloc? That would mean only that kmallocs >32k would require an additional determination of the kmalloc cache at run time.
But then how important is gcc 3.3 support?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |