Messages in this thread | | | Date | Fri, 6 Jan 2006 00:58:08 +0100 | From | Ingo Molnar <> | Subject | Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers |
| |
* Matt Mackall <mpm@selenic.com> wrote:
> > so i think the two concepts could nicely co-exist: in-source annotations > > help us maintain the popularity list, -ffunction-sections allows us to > > reorder at link time. In fact such a kernel could be shipped in > > 'unlinked' state, and could be relinked based on per-system profiling > > data. As long as we have KALLSYMS, it's not even a big debuggability > > issue. > > I'm still not sure about in-source annotations for popularity. My > suspicion is that it's just too workload-dependent, and a given > author's workload will likely be biased towards their code.
in-source annotations can do more:
- inlines could be driven by profile data: if a function is used in a hot path and it's used only once, it makes sense to inline that function into that hot path - because the kernel size increase will be in the cold portion.
- we could drive the likely/unlikely annotations via profiling data.
OTOH i think that _most_ of the benefit (80% :-) could be achieved via the much simpler (and more robust) link-time-reordering solution. It is also alot less intrusive, and can still be presented in some plain-text format that can be distributed along the upstream kernel:
linux/profiles/webserver.list linux/profiles/database-server.list linux/profiles/desktop.list linux/profiles/beowulf-node.list
and users could pick their profile at build time / relink time. There is no binary compatibility problem with such plaintext lists - they dont have to be fully complete, nor do they have to be fully accurate - they dont impact correctness in any way. In fact profiles could merge all architectures into one file, so they would be pretty generic as well.
Ingo - 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/
| |