From: Andi Kleen <ak@suse.de>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: Andi Kleen <ak@suse.de>, "David S. Miller" <davem@redhat.com>,
torvalds@transmeta.com, linux-kernel@vger.kernel.org, "Mallick,
Asit K" <asit.k.mallick@intel.com>,
"Saxena, Sunil" <sunil.saxena@intel.com>
Subject: Re: [PATCH] fixes for building kernel using Intel compiler (lmben ch data)
Date: Sat, 26 Oct 2002 08:27:23 +0200 [thread overview]
Message-ID: <20021026082723.C23915@wotan.suse.de> (raw)
In-Reply-To: <F2DBA543B89AD51184B600508B68D4000ECE70F1@fmsmsx103.fm.intel.com>
On Fri, Oct 25, 2002 at 07:16:49PM -0700, Nakajima, Jun wrote:
> pgoipo -- P70 + PGO (profile-guided optimization) + IPO (interprocedural
> optimization)
That is interesting. I assume you built a custom profiling driver for this.
One problem I see is that profile feedback will make the kernel images much less
predictible. Currently we need a vmlinux that matches the built kernel
to analyze any oopses etc. When there are small changes (bugfixes etc.)
the functions are still near enough that an oops can be meaningfully
looked at. But with profile based feedback this could completely change -
at least in gcc the profile feedback data has to exactly match the compiled
program. Now when I would change a single line I would need to reprofile
and then the resulting kernel could be totally different with every single
instruction changed, making it impossible to make any sense out of a
ksymoops. This could be a major problem for bug processing on linux-kernel
because the chances are small that I look at a vmlinux that is in any
way related to what the user has.
One way around would be to switch to lkcd crash images which include all
kernel code, but it could be a major problem to send them to a mailing list
because they're so big.
-Andi
next prev parent reply other threads:[~2002-10-26 6:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-26 2:16 [PATCH] fixes for building kernel using Intel compiler (lmben ch data) Nakajima, Jun
2002-10-26 6:27 ` Andi Kleen [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-10-28 14:47 Nakajima, Jun
2002-10-28 14:51 ` Andi Kleen
2002-10-28 15:03 ` Richard B. Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021026082723.C23915@wotan.suse.de \
--to=ak@suse.de \
--cc=asit.k.mallick@intel.com \
--cc=davem@redhat.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sunil.saxena@intel.com \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.