I don't think people need to use PGO for day-to-day development or
debugging. Rather, it would be used only for systems deployed for actual
use. For example, various kernel binaries optimized for particular use, such
as database, web server, file server, embedded systems, etc, can be
distributed as RPM (with profile feedback data).
For development we should such profile feedback data to optimize the kernel
in source code level (i.e by hand). I don't know the data in gcc has any
clue for that.
Jun
-----Original Message-----
From: Andi Kleen [mailto:[email protected]]
Sent: Friday, October 25, 2002 11:27 PM
To: Nakajima, Jun
Cc: Andi Kleen; David S. Miller; [email protected];
[email protected]; Mallick, Asit K; Saxena, Sunil
Subject: Re: [PATCH] fixes for building kernel using Intel compiler
(lmben ch data)
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
On Mon, Oct 28, 2002 at 06:47:27AM -0800, Nakajima, Jun wrote:
> I don't think people need to use PGO for day-to-day development or
> debugging. Rather, it would be used only for systems deployed for actual
> use. For example, various kernel binaries optimized for particular use, such
> as database, web server, file server, embedded systems, etc, can be
> distributed as RPM (with profile feedback data).
But unless these kernels are 100% bug free it still leaves the mainteance
issues open.
Also is it really that big a win ?
>
> For development we should such profile feedback data to optimize the kernel
> in source code level (i.e by hand). I don't know the data in gcc has any
> clue for that.
likely/unlikely is the clue. In fact it is already overused.
-Andi
P.S.: Your original mail mentioned that the "P4P kernel was instable
with gcc32". Could you elaborate on the instability? We're using
kernels compiled with gcc 3.2 all the time and they work just fine.
On Mon, 28 Oct 2002, Andi Kleen wrote:
> On Mon, Oct 28, 2002 at 06:47:27AM -0800, Nakajima, Jun wrote:
> > I don't think people need to use PGO for day-to-day development or
> > debugging. Rather, it would be used only for systems deployed for actual
> > use. For example, various kernel binaries optimized for particular use, such
> > as database, web server, file server, embedded systems, etc, can be
> > distributed as RPM (with profile feedback data).
>
> But unless these kernels are 100% bug free it still leaves the mainteance
> issues open.
Hmmm.... Where can I get a 100% bug-free kernel?
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Bush : The Fourth Reich of America