lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-01-06 01:02    [W:0.048 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site